A digital medical guide to CDK inhibitor therapy for cancer patients

Abstract

The present disclosure relates to a digital medical guide for patients undergoing oncology treatment. The patient may input symptoms into the prescription software. A wearable device may passively collect other health care data, such as biometric data, and / or physical activity data. Thus, the patient may be monitored using the prescription software and / or the wearable. Furthermore, the prescription software may be integrated with a biofluid testing system. For example, a home biofluid monitoring kit and / or a laboratory system may communicate with the prescription software and / or its back-end server. The health care data collected through the monitoring and biofluid testing may be fed into a machine learning model that may output whether the patient is likely to develop an adverse event, such as cytopenia. For example, one or more alert notifications to a physician dashboard and / or to the prescription software may be triggered when the machine learning model determines a high probability of such an adverse event.

Description

[Technical field]

[0001] Related Applications This application claims priority to U.S. Provisional Application No. 63 / 295,109, filed December 30, 2021, which is incorporated by reference in its entirety.

[0002] The subject matter presented herein is directed to systems and methods for monitoring breast cancer treatment, particularly for monitoring side effects associated with CDK inhibitor treatment for breast cancer. [Background technology]

[0003] Cancer occurs when cancer cells grow rapidly and crowd out normal cells. For breast cancer patients, cyclin-dependent kinase (CDK) inhibitors, such as palbociclib (e.g., Ibrance by Pfizer), are prescribed to inhibit the growth of cancer cells. However, there may be side effects of CDK inhibitor therapy. For example, for breast cancer patients undergoing CDK inhibitor therapy, there is a continued risk of cytopenia, specifically neutropenia. Another class of cancer treatments can include poly(ADP) ribose polymerase (PARP) inhibitors. PARP inhibitors prevent cancer cells from repairing damaged DNA (e.g., caused by other anticancer drugs), thus killing the cancer cells. PARP inhibitors may have side effects such as cytopenia, specifically thrombocytopenia and neutropenia. Other tumor treatments also have side effects.

[0004] Traditional side effect management for oncology treatment (e.g., CDK inhibitor treatment, PARP inhibitor treatment, etc.) is inadequate. For example, detection of cytopenia requires frequent biofluid testing, e.g., blood testing, about 12 times per year. Frequent biofluid testing may not be readily available to patients, especially those in remote areas. Furthermore, biofluid testing regimens may be inconvenient because they require physical visits to a laboratory, and patients may not always adhere to these inconvenient testing regimens. To exacerbate the problem, traditional side effect management is based on scattered clinical interviews with limited face-to-face time between patients and physicians. Thus, scattered clinical interviews may provide an incomplete picture of the patient's condition, often based on biased information from the patient (e.g., due to recall bias). These limited interviews with incomplete information sharing may not be sufficient for early detection of oncology treatment side effects such as cytopenia. For example, a breast cancer patient may consistently feel fatigue and weakness (symptoms of cytopenia), which the patient may interpret as normal for cancer patients and may not report to the physician during the appointment. Failure to timely report different symptoms to the physician during scattered clinical appointments may not be adequate for preventive management of oncology treatment side effects. Summary of the Invention [Means for solving the problem]

[0005] In some embodiments, the present disclosure relates to a digital medical guide for patients undergoing oncology treatment (e.g., CDK inhibitor treatment, PARP inhibitor treatment). In one embodiment, the patient may be provided with prescription software, such as a smartphone application. The prescription software may allow the patient to input symptoms, e.g., "feeling tired". The wearable device may passively collect other health care data, such as biodata (e.g., heart rate, temperature, etc.) and / or physical activity data (e.g., movement, exercise, etc.). Thus, the patient may be continuously or nearly continuously monitored using the prescription software and / or the wearable. Furthermore, the prescription software may be integrated with a biofluid testing system. For example, a home biofluid monitoring kit and / or a laboratory system may communicate with the prescription software and / or its back-end server. The health care data collected through the monitoring and biofluid testing may be fed into a machine learning model that may output whether the patient is likely to develop an adverse event, such as a cytopenia. For example, one or more alert notifications to the physician dashboard and / or to the prescription software may be triggered when the machine learning model determines a higher likelihood of such an adverse event. Such prediction and corresponding notification may enable physicians to intervene proactively to manage and mitigate side effects.

[0006] In one embodiment, a computer-implemented method may be provided. The method may include: acquiring first health data including symptoms of a patient undergoing cyclin-dependent kinase (CDK) inhibitor treatment; acquiring second health data including an analysis of a biological fluid sample collected from the patient; deploying a machine learning model on the first health data and the second health data to predict whether the patient will develop a side effect associated with the CDK inhibitor treatment; and in response to the machine learning model predicting that the patient is likely to develop the side effect, generating a message to be transmitted to a physician dashboard to trigger a notification on the physician dashboard.

[0007] In another embodiment, another computer-implemented method may be provided. The method may include: acquiring first health data including symptoms of a patient undergoing cyclin-dependent kinase (CDK) inhibitor treatment; acquiring second health data including an analysis of a biological fluid sample collected from the patient; deploying a machine learning model on the first health data and the second health data to predict whether the patient will develop a side effect associated with the CDK inhibitor treatment; and in response to the machine learning model predicting that the patient is likely to develop the side effect, generating a message to be transmitted to a healthcare application executing on a client device associated with the patient to trigger a notification on the healthcare application.

[0008] In yet another embodiment, a system is provided, which may include one or more processors and a non-transitory storage medium storing computer program instructions that, when executed by the one or more processors, cause the system to perform operations, including: acquiring first health data including symptoms of a patient undergoing cyclin-dependent kinase (CDK) inhibitor treatment; acquiring second health data including an analysis of a biological fluid sample collected from the patient; deploying a machine learning model on the first health data and the second health data to predict whether the patient will develop a side effect associated with the CDK inhibitor treatment; and triggering one or more notifications in response to the machine learning model predicting that the patient is likely to develop the side effect.

[0009] Other objects and advantages of the present disclosure will become apparent to those of ordinary skill in the art upon reading the following detailed description of exemplary embodiments and the appended claims, in conjunction with the accompanying drawings, where like reference numerals are used to designate like elements. [Brief description of the drawings]

[0010] [Figure 1]FIG. 1 is a block diagram of an illustrative operating environment for using one or more embodiments of the present disclosure. [Diagram 2] FIG. 1 is a block diagram of the architecture of an illustrative computing device that may perform one or more functions in accordance with some embodiments of the present disclosure. [Diagram 3] FIG. 1 is a block diagram of an exemplary architecture of an operating environment in which one or more embodiments disclosed herein may be used. [Figure 4] FIG. 1 is a flow diagram of an illustrative method for training a predictive model for predicting side effects of oncology treatment, according to some embodiments of the present disclosure. [Diagram 5] FIG. 1 is a flow diagram of an illustrative method for developing a predictive model for predicting side effects of tumor treatment, according to some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] It should be understood that the figures are for purposes of illustrating example embodiments and that the disclosure is not limited to the arrangements and instrumentality shown in the drawings, in which like reference numbers identify at least generally similar elements.

[0012] The embodiments disclosed herein may provide a digital medical guide for cancer patients undergoing oncology treatment (e.g., CDK inhibitor treatment, PARP inhibitor treatment, etc.). Oncology treatment is commonly associated with side effects such as cytopenia (e.g., neutropenia, thrombocytopenia), infections, etc. To predict, detect, and manage these symptoms, the digital medical guide may include, for example, prescription software, wearable sensors, integration with biofluid (e.g., blood, urine, saliva, nasopharyngeal fluid, etc.) testing systems (e.g., blood testing systems), and back-end analysis modules.

[0013] The prescription software may be provided in the form of a smartphone application that may allow the patient to input symptoms. The patient-entered symptoms may include, for example, how the patient is feeling (e.g., fatigued), whether the patient is feverish, the patient's appetite level, and / or other types of biological and psychological symptoms. The wearable sensor may passively (e.g., without the patient's involvement) collect data such as movement data (e.g., activity level), and / or biometric data (heart rate, blood oxygen saturation). Integration with a biofluid testing system may allow for the acquisition of biofluid analysis (e.g., blood test) data from any type of biofluid testing (e.g., at-home testing kits, lab tests). The back-end analysis module may use one or more machine learning modules to predict whether the patient is likely to develop an adverse event based on the patient-entered data in the prescription software, the passively collected data from the wearable, and / or the biofluid analysis data from the integrated biofluid testing system. If the machine learning module predicts a higher likelihood that the patient will develop an adverse event, one or more notifications to the physician dashboard and / or the prescription software may be generated. One or more notifications may allow for timely clinical intervention and thus preventative management of side effects.

[0014] It should be understood that the following embodiments describing a digital medical guide for tumor treatment are merely examples and should not be considered limiting. The embodiments may be equally applicable to managing side effects associated with different treatment regimens for non-tumor diseases. Furthermore, the side effects described below (e.g., cytopenias) are also merely examples, and the embodiments may be equally applicable to other unlisted side effects as well.

[0015] FIG. 1 shows a block diagram of an exemplary operating environment 100 for using one or more embodiments of the present disclosure. It should be understood that this and other arrangements described herein are set forth merely as examples. Other arrangements and elements (e.g., machines, interfaces, functions, sequences, and groups of functions) may be used in addition to or instead of those shown in FIG. 1 and other figures, and some elements may be omitted entirely for clarity. Furthermore, many of the elements described herein are functional entities that may be implemented as separate or distributed components, or in conjunction with other components, and in any suitable combination or location. Various functions and operations described herein are performed by one or more entities, including hardware, firmware, software, and combinations thereof. For example, some functions may be performed by a processor executing instructions stored in a memory.

[0016] As shown, the operating environment 100 may include patient user devices 102a-102n (collectively or commonly referred to as devices 102), biological fluid sampling devices 110, a server 106, an electronic health record (EHR) system 104, a network 112, hospital devices 140, a data store 150, and physician user devices 108. It should also be understood that the description of devices in singular or plural is merely for clarity in the description and should not be considered limiting. For example, the server 106 may include multiple servers and the physician user devices 108 may include multiple user devices. The different devices in the operating environment 100 may be interconnected through a network 112.

[0017] The patient-directed user devices 102 may include any type of computing and / or sensing device with which a patient may interact. Non-limiting examples shown within the operating environment 100 may include a smart watch 102a, a mobile device 102b (e.g., a smartphone), other smart sensors 102c (e.g., smart rings, invisible sensors such as motion sensors, etc.), a fitness tracker 102d, and other patient-directed user devices 102n (e.g., tablets, laptop computers, desktop computers, smart speakers, smart home systems, etc.). The patient-directed user devices 102 may either passively collect or actively prompt the patient to enter data associated with the management of side effects associated with oncology treatments (e.g., CDK inhibitors such as Pfizer's Ibrance, PARP inhibitors, etc.).

[0018] For example, the smartwatch 102a may have multiple sensors to passively collect data from the patient. The multiple sensors may include accelerometers, gyroscopes, and / or other types of motion sensors that may track the patient's physical activity. The smartwatch 102a may further include sensors to detect biological parameters, such as body temperature, heart rate, blood glucose level, blood oxygen saturation, and / or any other type of biological parameter. The biological parameters may be collected by the smartwatch 102a continuously and / or periodically - e.g., without the patient's explicit involvement in the collection - and provided to other components (e.g., server 106) in the operating environment.

[0019] The mobile device 102b may be used by the patient to actively input health-related data. For example, the mobile device 102d may be a smartphone in which a healthcare application, for example, an electronic patient-reported outcome (ePRO) application, may be installed. The healthcare application may prompt the patient to input health-related data. The health-related data may include, for example, symptoms the patient is experiencing. For example, the symptoms may include "feeling tired," "feeling weak," "feeling great," and the like. As another example, the patient may input symptoms in response to a push notification generated within the operating environment 100. For example, the healthcare application may generate a push notification for the patient to input data regarding how the patient is feeling at a given point in time. The prompt may be "How are you feeling this morning?" and the patient may input "feeling great." The healthcare application may also display an alert notification, which may be generated when the operating environment 100 determines that there is a possible risk of cytopenia, neutropenia, infection, and the like. Another type of alert notification displayed by the healthcare application may be when the patient's current disease behavior significantly deviates from an established baseline behavior. Accordingly, healthcare applications may further enable patients to communicate with physicians synchronously or asynchronously.

[0020] The other sensors 102c may include devices such as smart rings, skin patches, ingestible sensors, and / or any other type of body-worn or non-body-worn sensors (commonly referred to as invisible or invisible devices / sensors). The other sensors 102c may detect biometric or non-biometric data. For example, the other sensors 102c may include smart fabrics that measure the patient's body temperature. As another example, the other sensors 102c may include smart home sensors that measure the temperature and / or humidity of a home. As yet another example, the other sensors 102c may include motion sensors that may detect / measure movement in a room. The other patient devices 102n may include any other type of device associated with a patient. For example, the other patient devices 102n may include tablet computers, laptop computers, desktop computers, and / or other devices associated with a patient and connected to the network 112.

[0021] The biological fluid sampling device 110 may include any type of biological fluid (also referred to as bodily fluid) monitoring device and / or service that may collect and analyze a patient's biological fluid sample. The biological fluid may include, for example, blood, saliva, urine, nasopharyngeal fluid, etc. For example, the biological fluid sampling device 110 may include a mail-home sample collection kit that may allow a patient to draw blood and / or collect another biological fluid and send the kit back to a laboratory for analysis. In other cases, the biological fluid sampling device 110 may include a mail-home sample collection kit that may perform at least a portion of the analysis itself and provide the results of the analysis in one or more of the patient-directed device 102 and / or server 106. The biological fluid sampling device 110 should further be understood to include monitoring devices used by physicians, in a laboratory environment, or in a home visit environment. Thus, any type of technology and / or service used to collect patient biological fluid samples and analyze the samples for biological parameters should be considered within the scope of this disclosure. An example of a biological parameter measured by the biological fluid sampling device 110 may include the white blood cell count in the blood, where a lower white blood cell count may indicate the onset of cytopenia.

[0022] The network 112 may include any type of communication network. For example, the network 112 may include a packet switching network supporting protocols such as TCP / IP. The network 112 may also include a circuit switching network supporting both wired and wireless telephony. Thus, the network 112 may include components such as wires, wireless transmitters, wireless receivers, signal repeaters, signal amplifiers, switches, routers, communications satellites, and / or any other type of network and communication devices. Some non-limiting examples of the network 112 may include a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN) such as the Internet, and the like. These are merely a few examples of the network 112, and any type of communication linkage between different components of the operating environment 100 should be considered within the scope of the present disclosure.

[0023] The server 106 may include any type of computing device that can provide analytical capabilities to train and deploy one or more machine learning models and / or establish and deploy statistical analysis models. For example, the server 106 may train a predictive model to predict side effects, such as whether a patient under a tumor treatment regimen (e.g., a CDK inhibitor treatment regimen) will develop side effects. The predictive model may be trained using a supervised training approach with labeled ground truth data. The predictive model may include, for example, a regression model, a gradient boosting regression model, a logistic regression model, a random forest regression model, an ensemble model, a classification model, a deep learning neural network, a recurrent neural network for deep learning, or a convolutional neural network for deep learning.

[0024] The machine learning-based predictive model described above is merely an example, and other statistical models should be considered within the scope of the present disclosure. For example, the server 106 may also establish an analytical model based on continuously collected time-series healthcare data, and the analytical model may indicate a baseline health behavior. When new healthcare data is received, the server 106 may compare the received data with the analytical model (e.g., against the baseline health behavior) to determine whether the new healthcare data indicates a significant deviation from the baseline health behavior. The server 106 may also generate one or more alert notifications, for example, to the patient and / or physician indicating that the patient is likely to develop one or more adverse conditions (e.g., cytopenia, neutropenia, etc.) and / or that the patient's health behavior has significantly deviated from the baseline behavior.

[0025] An electronic health record (EHR) 104 may store a patient's health record. The health record may include, for example, a patient's ongoing medical condition (e.g., breast cancer), prescription medications, clinical encounter summaries, and / or any other health care related data associated with the patient. In some embodiments, the EHR 104 may be managed by a health care delivery institution (e.g., a hospital system).

[0026] Data store 150 may include any type of database that stores data collected from various sources within operating environment 100. For example, data store 150 may store both passively and actively collected data from patient directed devices 102. Data store 150 may also store data collected from biological fluid sampling devices 110. Additionally, data store 150 may store data sourced from EHR 104. Thus, data source 150 should be understood to store any type of data within operating environment 100.

[0027] The physician user device 108 may be any type of computing device that presents a physician dashboard. Non-limiting examples of the physician user device 108 may include a mobile phone (e.g., a smartphone), a tablet computer, a laptop computer, a desktop computer, and / or any other type of computing device. The physician dashboard may present information (e.g., demographic information, location information), and / or one or more alerts associated with various patients.

[0028] 2 shows a block diagram of an illustrative computing device 200 that may perform one or more functions described herein, according to some embodiments of the present disclosure. However, the computing device 200 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the embodiments of the present disclosure. The computing device 200 should not be interpreted as having any dependency or requirement relating to any one or combination of illustrated components.

[0029] The embodiments of the present disclosure may be described in the general context of computer code or machine usable instructions, including computer usable or computer executable instructions, such as program modules, executed by a computer or other machine, such as a personal data assistant, smartphone, tablet PC, or other handheld or wearable device, such as a smart watch. Generally, a program module, including routines, programs, objects, components, data structures, and the like, refers to code that may perform specific tasks or implement specific data types. The embodiments of the present disclosure may be practiced in a variety of system configurations, including handheld devices, consumer electronics, general-purpose computers, or more specialized computing devices. The embodiments of the present disclosure may also be practiced in distributed computing environments where tasks are performed by remote processing devices 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.

[0030] The computing device 200 may include a bus 210 that may directly or indirectly couple the following example devices: memory 212, one or more processors 214, one or more presentation components 216, one or more input / output (I / O) ports 218, one or more I / O components 220, and a power source 222. Some embodiments of the computing device 200 may further include one or more radios 224. The bus 210 represents what one or more buses may be (such as an address bus, a data bus, or a combination thereof). Although the various blocks in FIG. 2 are shown with lines for clarity, these blocks may represent logical components and do not necessarily represent actual components. For example, one may consider the presentation components 216, such as a display device, to be I / O components. The processors 214 may also have their own memory. Furthermore, no distinction is made between categories such as "workstations," "servers," "laptops," or "handheld devices," all of which are contemplated within the scope of FIG. 2 and in relation to "computing devices."

[0031] Computing device 200 may include a variety of computer readable media. Computer readable media may be any available media that can be accessed by computing device 200 and may include both volatile and nonvolatile, removable and non-removable media. By way of example and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media may include both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. Some non-limiting examples of computer readable media may include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by computing device 200. Communication media may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and include any information delivery media. The term "modulated data signal" may refer to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media may include wired media, such as a wired network or direct-wired connection, and wireless media, such as acoustic, RF, infrared and other wireless media. Combinations of any of the above are also intended to be included within the scope of computer-readable media.

[0032] The memory 212 may include computer storage media in the form of volatile and / or non-volatile memory. The memory 212 may be removable, non-removable, or a combination thereof. Some non-limiting examples of hardware devices for the memory 212 include solid-state memory, hard drives, optical disk drives, and the like.

[0033] Computing device 200 may include one or more processors 214 that read data from various entities, such as memory 212 or I / O components 220. A presentation component 216 may present a representation of the data to a user or other device. Exemplary presentation components may include display devices, speakers, printing components, and the like.

[0034] The I / O port 218 may allow the computing device 200 to be logically coupled to other devices, such as an I / O component 220, some of which may be built-in. Non-limiting examples of the I / O component 220 may include a microphone, a joystick, a gamepad, a satellite dish, a scanner, a printer, or a wireless device. The I / O component 220 may provide a natural user interface (NUI) that processes air gestures, voice, or other physiological input generated by a user. In some cases, the input may be transmitted to an appropriate network element for further processing. The NUI may implement any combination of voice authentication, touch and stylus authentication, face authentication, biometric authentication, gesture authentication both on or near the screen, air gestures, head and eye tracking, and touch authentication associated with a display on the computing device 200. The computing device 200 may be equipped with cameras, such as a stereoscopic camera system, an infrared camera system, an RGB camera system, and combinations thereof, for gesture detection and authentication. Additionally, computing device 200 may be equipped with an accelerometer or gyroscope to enable detection of movement.

[0035] Some embodiments of computing device 200 may include one or more radios 224 (or similar wireless communication components). A radio may transmit and receive radio or wireless communications. Computing device 200 may be a wireless terminal adapted to receive communications and media over various wireless networks. Computing device 200 may communicate via wireless protocols such as Code Division Multiple Access ("CDMA"), Global System for Digital Cellular Communications ("GSM"), or Time Division Multiple Access ("TDMA"), as well as others, to communicate with other devices. Wireless communications may be short-range connections, long-range connections, or a combination of both short-range and long-range wireless telecommunications connections.

[0036] 3 shows a block diagram of an exemplary architecture of an operating environment 300 in which one or more embodiments disclosed herein may be used. The architecture shown may be implemented by one of more components / devices of the operating environment 100 shown in FIG. 1 (e.g., computing device 200 shown in FIG. 2). However, it should be understood that the architecture shown is merely an example, and that architectures with additional, alternative, or fewer components should also be considered within the scope of the present disclosure. It should be further understood that components shown as a single component or multiple components are also merely examples, and that a single component may include multiple iterations of the same component or multiple constituent subcomponents, and that the functionality of multiple components may be achieved by a single component.

[0037] The operating environment 300 may be used for continuous or near-continuous digital monitoring of patients undergoing oncology treatment regimens, such as CDK inhibitor treatment regimens (e.g., Pfizer's Ibrance), PARP inhibitor treatment regimens, and the like, and triggering alert notifications to patients and / or physicians as needed. Furthermore, the operating environment 300 may provide seamless and continuous connectivity between patients and physicians. This continuous or near-continuous monitoring may enable preventative management of side effects associated with oncology therapeutics, and machine learning models may predict the onset of one or more pathologies, thereby facilitating early clinical intervention for those conditions. The operating environment 300 may further have seamless integration of biofluid monitoring data sources 340, such that biofluid analyses (e.g., blood tests) may be tracked continuously to detect / predict cytopenias. To perform these and other functions, the operating environment 300 may include patient-facing devices (e.g., wearable devices 302a, patient user devices 302b, other sensors 302c, etc.) to collect healthcare data and other data from the patient, provide alert notifications to the patient and / or physician, and facilitate communication between the physician and the patient. Data collected from the patient-facing devices 302 and biofluid monitoring data sources 340 may be stored in storage 370 (e.g., personal records 380). An analysis component (e.g., side effect predictor 350) may use the stored data and other data to predict and / or detect side effects associated with oncology therapeutics. Based on the analysis, an alert notification may be sent to the physician (e.g., via physician user device 308). The components of the operating environment 300 may be interconnected through a network 310.

[0038] With respect to the patient-facing devices 302, these devices may include, for example, wearable devices 302a, patient user devices 302b, and other sensors 302c. The wearable devices 302a may include any type of wearable device, non-limiting examples include smart watches, fitness trackers, smart rings, and the like. In some embodiments, the wearable devices 302a may include a healthcare application 322. The wearable devices 302a or any applications installed thereon (e.g., the healthcare application 322) may be medically prescribed components within the operating environment 300. The healthcare application 322 may be a computer program installed on the wearable devices 302a to collect healthcare data, in some cases perform pre-processing of the collected data, and transmit the data to the patient-user devices 302b or to a remote server (e.g., a server implementing the side effect predictor 350 and / or the storage 370). In particular, the healthcare application 322 may interface (e.g., through API calls) with the operating system of the wearable device to collect data from the sensors 324.

[0039] The sensors 324 may include any type of sensor that may continuously or periodically collect data from a patient wearing the wearable device 302a. For example, the sensors 324 may include biosensors such as a temperature sensor to measure body temperature (it should be understood that the temperature sensor may be non-biological and may measure ambient temperature), a heart rate monitor, an electrocardiogram sensor to collect electrocardiogram data when prompted by the patient, a glucose monitor, a sweat monitor, a blood oxygen saturation monitor, a blood pressure monitor, and / or any other type of biosensor. The sensors 324 may also include an accelerometer to determine directional movement, a gyroscope to detect orientation, and / or any other type of sensor to collect position or motion data. These sensors 324 may be triggered by the healthcare application 322 (e.g., through an API call to the operating system of the wearable device 302a) to collect the corresponding data. Alternatively, the wearable device 302a may not have a healthcare application 322, and the trigger may be received from the patient user device 302b (e.g., from its healthcare application 332) or remotely through the network 310. In other embodiments, the wearable device 302a may itself continuously or periodically activate the sensor 324 and communicate collected sensor data to the healthcare application 324 (and / or the healthcare application 332, or a remote device connected via the network 310). The biometric data and motion data collected by the sensor 324 may be collectively or commonly referred to as healthcare data (or health data).

[0040] In other words, the sensor 324 may passively collect healthcare data without the active involvement of the patient. For example, the sensor 324 may monitor the patient's biometric data and / or physical movements because the sensor 324 is in the wearable device 302a and thus is continuously worn by the patient. Such passive collection of healthcare data does not require the patient's continuous attention and is therefore less burdensome.

[0041] The patient user device 302b may include any type of computing device used by a patient. For example, the patient user device 302b may include a mobile phone such as a smartphone, a tablet device, a laptop computer, a desktop computer, and / or any other type of computing device. Healthcare applications 332 (e.g., ePRO) may be installed on the patient user device 302b. It should be understood that the healthcare applications 332 include standalone applications (e.g., smartphone apps) or web-based applications (e.g., accessed using a browser). It should be further understood that the healthcare applications 332 may also be medically prescribed. The healthcare applications 332 may provide an interface (e.g., a graphical user interface) for the patient to view alert notifications, communicate with a physician, and / or actively input healthcare data (e.g., observed symptoms).

[0042] As an example, the healthcare application 332 may be used to gather further information regarding predictions based on data collected by the wearable device's sensor 324. For example, using passively collected data, the side effect predictor 350 may predict the onset of side effects of oncology treatments (e.g., CDK inhibitors, PARP inhibitors, etc.). For example, the wearable device's 302a sensor 324 may measure less body movement compared to an established baseline, and the side effect predictor 350 may predict that the patient may be experiencing fatigue. In response to this prediction, an alert notification may be sent (e.g., by the communication facilitator 358) to the healthcare application 332. The alert notification may be, for example, "Low activity level detected. Do you feel fatigued?", prompting the patient to respond. For response, the healthcare application 332 may provide options such as "extreme fatigue," "moderate fatigue," or "not feeling fatigued." As another example, the wearable device's 302a sensor 324 may measure a lower than normal heart rate. In response to this determination, the server may transmit another alert notification to the healthcare application 332. The alert notification may be, for example, "Low heart rate detected. Are you dizzy?", prompting the patient to respond. For response, the healthcare application 332 may provide options such as "extreme dizziness," "moderate dizziness," or "no dizziness." These are just some examples of alert notifications to the patient, and other types of alert notifications should be considered within the scope of this disclosure.

[0043] In addition to prompts corresponding to alert notifications, the healthcare application 332 may periodically (e.g., without triggering data entry) request the user to enter healthcare data. For example, the healthcare application 332 may prompt the patient to enter symptoms observed every morning, noon, and night. Other non-limiting examples of actively entered data include body temperature (if not collected by the sensor 324 of the wearable device 302a), bowel movements, pain levels experienced, stress levels, anxiety levels, time of taking prescription medications, athletic activity (if not captured by the wearable device 302a), and / or any other type of healthcare data.

[0044] In addition to alert notifications, the healthcare application 332 may also provide bidirectional connectivity between the patient and the physician. The bidirectional connectivity between the patient and the physician may be facilitated by the communication facilitator 358 of the side effect predictor 350. The bidirectional connectivity may allow the patient to establish any type of synchronous (e.g., audio or video call) or asynchronous (e.g., message exchange) with the physician. The bidirectional connectivity may be initiated in response to an alert notification. For example, the side effect predictor 350 may predict the onset of a cytopenia and the communication facilitator 358 may generate an alert that is provided on the healthcare application 332. When the patient selects the alert notification (e.g., a notification badge), an interface may be provided by the healthcare application 332 for the patient to initiate a communication session with the physician (e.g., messaging or calling the physician). For example, the patient may pose a question through the healthcare application 332 itself and the physician's response may be displayed within the healthcare application 332. The bidirectional connectivity may also be leveraged to provide educational material to the patient. The educational materials in some embodiments may include cognitive behavioral therapy (CBT) based behavior change encouragement materials. These materials may be provided to the patient based on healthcare data passively collected by the wearable device 302a, actively collected by the patient user device 302b, and analyzed by the side effect predictor 350. The CBT-based materials may be in audio, video, and / or text form and may encourage the patient to make healthier choices regarding diet (e.g., the BRAT (banana, rice, applesauce, toast) diet, rest and exercise, stress management, and / or any other metrics associated with maintaining a good quality of life while under an oncology treatment regimen.

[0045] However, it should be understood that connectivity through the healthcare application 332 is merely an example, and other types of connectivity should also be considered within the scope of the present disclosure. For example, bidirectional connectivity may be established through other components other than the healthcare application 332. For example, a patient may call a doctor, send an email, send a message, etc., without necessarily using the healthcare application for these types of communications.

[0046] The sensor 334 in the patient user device 302b may include any type of sensor, such as a heart rate sensor (e.g., when the patient holds the patient user device 302b close to the body), a glucose monitor (e.g., using an infrared camera), an accelerometer, a gyroscope, etc. In general, any type of biometric and / or motion sensor should be considered within the scope of the present invention. For example, if the patient user device 302b is a mobile device (e.g., a smartphone), the patient user device 302b may also monitor the user's motion using the sensor 334. The sensor 334 may detect the number of steps taken by the patient throughout the day, and / or other activities (e.g., exercise) performed by the patient throughout the day. In other words, the sensor 334 may also be used to passively collect patient motion data. In some embodiments, the sensor 334 may enable active data collection. For example, the sensor 334 may include an infrared camera, and the patient user device 302b may prompt the patient to hold a finger over the camera to detect biological attributes such as blood glucose level, blood oxygen saturation, etc. In another example, the sensor 334 may include a heart rate sensor that, when placed close to the patient's body, may measure the patient's heart rate.

[0047] The camera 336 may include an optical camera that the patient may use to take health care-related photographs. The photograph may be a photograph of the relevant body part, e.g., the patient's hand showing a skin condition. The photograph may be transmitted to storage 370 and / or provided to a physician. The physician may use the photograph for diagnostic purposes (e.g., to determine if a particular side effect is improving or worsening) and / or therapeutic purposes (e.g., to determine if the dosage of a medication the patient is taking should be adjusted).

[0048] The other sensor 302c may be any type of sensor that measures one or more biological or physical attributes of the patient. An example of the other sensor 302c may be an ingestible sensor that may measure the effect of an oncology treatment regimen and / or other related prescription medications on digestive activity. Another example may be a patch sensor that may be worn on the skin to measure attributes such as skin temperature and / or movement of the body part to which the patch sensor is worn. The sensor 302c may further include a blood pressure monitor that may communicate measurements to the patient user device 302b or any other device in the operating environment 300. Other examples of the sensor 302c may include smart fabrics, smart belts, subcutaneous sensors, and the like. These are merely some examples of sensors, and any type of body-worn or non-body-worn sensor should be considered within the scope of this disclosure. Non-body-worn sensors may be referred to as invisible or invisible sensors / devices.

[0049] The biofluid monitoring data source 340 can be any type of biofluid (e.g., blood, urine, saliva, nasopharyngeal fluid) analysis device or system. For example, the biofluid monitoring data source 340 can include a home sample collection kit. The home sample collection kit can be mailed to the patient's home and used by the patient to collect a sample to be sent to a laboratory. The laboratory can then perform the biofluid analysis (e.g., determine the white blood cell count in the blood sample) and provide the analysis data to other components of the operating environment 300 (e.g., storage 370) over the network 310. In other embodiments, the home collection kit can have some sample analysis capabilities in combination with the patient user device 302b, for example, an analysis component in the kit can connect with the patient user device 302b to provide the measured data.

[0050] Biological fluid monitoring data sources 340 may further include other types of sources, such as testing laboratories, examination rooms, and / or any type of equipment and / or facilities for collecting and analyzing biological fluid samples. Regardless of its type, biological fluid monitoring data sources 340 may provide measured data to other components within operating environment 300 (e.g., over network 310).

[0051] As described above, data collected by one or more of the wearable device 302a, the patient user device 302b, the other sensors 302c, and the biofluid monitoring data source 340 - either passively or actively - may be received by other components in the operating environment through the network 310. The network 310 may include any type of communication network. For example, the network 310 may include a packet switching network that supports protocols such as TCP / IP. The network 310 may also include a circuit switching network that supports both wired and wireless telephony. Thus, the network 310 may include components such as wires, wireless transmitters, wireless receivers, signal repeaters, signal amplifiers, switches, routers, communication satellites, and / or any other type of network and communication devices. Some non-limiting examples of the network 310 may include a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN) such as the Internet, and the like. These are merely a few examples, and any type of communication linkage between different components of the operating environment should be considered within the scope of this disclosure.

[0052] Data received from patient-facing devices (e.g., wearable devices 302a, patient user devices 302b, other sensors 302c, etc.) and biofluid monitoring data sources 340 may be stored in storage 370. Storage 370 may include any type of storage technology, such as hard drive storage, solid state storage, data server storage, etc. Although a single storage 370 is shown for clarity of explanation, it should be understood that storage 370 includes multiple geographically distributed components. For example, storage 370 may be distributed across multiple data centers and incorporate multiple levels of redundancy.

[0053] In some embodiments, storage 370 may store an individual record 380 that includes data for a corresponding patient. In other words, the individual record 380 may be associated with a patient. However, it should be understood that this individual record 380-based data organization is merely an example and should not be considered limiting. Any type of data organization (e.g., relational, object-oriented) should be considered within the scope of this disclosure.

[0054] As shown, the patient's personal record 380 may include profile / health data (e.g., electronic health record (EHR) data) 381, sensor data 382, ​​patient-entered data 383, contextual data 384, and past event log 385. However, these are merely some examples of data types within the personal record 380, and additional, alternative, or fewer data types should also be considered within the scope of this disclosure. Moreover, the separate data types shown herein are likewise merely examples, and the data types may include aspects of other data types. For example, the profile / health data may incorporate past event log 381.

[0055] Profile / health data 381 may include the corresponding patient's electronic medical record. Thus, profile / health data 381 may include demographic information, comprehensive medical history, family history, allergies, ongoing medical conditions, clinical interview records, other notes from physicians, prescription medications, laboratory results such as blood test results, and / or any other type of healthcare data for the patient. For example, profile / health data 381 may include information regarding a treatment regimen using a CDK inhibitor and any observed side effects upon administering the CDK inhibitor. As another example, profile / health data 381 may include information regarding a treatment regimen using a PARP inhibitor and any observed side effects upon administering the PARP inhibitor. In some embodiments, profile / health data 381 may be provided to storage 370 from other entities. For example, profile / health data 381 may be managed by a healthcare provider (e.g., a hospital), and operating environment 300 may obtain data from the healthcare provider.

[0056] The sensor data 382 may be data from patient-facing sensors, such as the sensors 324 of the wearable device 302a, the sensors 334 of the patient user device 302b, and / or other sensors 302c. Thus, the sensor data 382 may include data from biosensors (e.g., heart rate monitors, blood pulse oximeters), motion sensors (e.g., accelerometers and / or gyroscopes), and / or any other type of sensor. The sensor data 382 may be stored in association with a timestamp of when the data was collected. The timestamp may enable the operating environment 300 to detect the patient's activities and conditions throughout the day. As used herein, the sensor data 382 should be understood to generally include any type of passively collected data (e.g., motion passively detected by a wearable) or data captured by a patient actively engaging with a sensor (e.g., a patient places a finger over an infrared camera to measure various biological attributes).

[0057] The patient-entered data 383 may include any type of data actively entered by the patient (e.g., through the healthcare application 332). Thus, the patient-entered data 383 may include the patient's input regarding the patient's symptoms at a particular point in time (e.g., "fatigued," "depressed," etc.). As another example, the patient-entered data 383 may include the patient's reactions to various alert notifications provided by the healthcare application 332. The patient-entered data 383 may further include other biometric data not captured by a sensor (e.g., sensors 324, 334, and / or 302c). For example, such biometric data may include blood glucose levels, blood oxygen saturation, blood pressure, etc., captured by devices (e.g., external blood pressure monitors) operating with active user involvement within the operating environment 300. Similar to the sensor data 382, ​​the patient-entered data 383 may also be organized using a timestamp. In other words, the timestamp may be used to correlate the sensor data 382 and the patient-entered data 383.

[0058] The contextual data 384 may include any type of information that may provide additional context to the sensor data 382 and / or the patient-input data 383. For example, the contextual data 384 may include data from the biofluid monitoring data source 340. As another example, the contextual data may include geographic information about the patient (e.g., what part of the country the patient lives in), information about the medical conditions of cohorts similar to the patient. In general, any type of information that generates additional healthcare data points within the operating environment 300 should be considered contextual data 384. Like the sensor data 382 and the patient-input data 383, the contextual data 384 may also be time-stamped so that these three types of data may be correlated in time during further analysis (e.g., by the side effect predictor 350).

[0059] The past event log 385 may include records of events associated with a patient. For example, the past event log 385 may include other information regarding clinical encounters, prescription fillings and refills, and / or any other type of events associated with managing side effects of an oncology treatment regimen. The past event log 385 may also be time-stamped so that these logs may be temporally correlated with one or more of the sensor data 382, ​​the patient input data 383, or the contextual data 384.

[0060] An analytical component (e.g., side effect predictor 350) may use the individual records 380 (and / or other types of data) in storage 370 to generate / train one or more machine learning models (and / or any other type of analytical models) and then deploy the trained models for one or more of predicting the onset of side effects, such as cytopenias.

[0061] The side effect predictor 350 may predict the likelihood of a side effect for a patient undergoing an oncology treatment regimen. Such prediction may be based on using a predictive model 352, which may be trained by a model trainer 354 and deployed by a model deployer 356. The predictive model 352 may include, for example, a regression model, a gradient boosting regression model, a logistic regression model, a random forest regression model, an ensemble model, a classification model, a deep learning neural network, a recurrent neural network for deep learning, or a convolutional neural network for deep learning.

[0062] The model trainer 354 may train the predictive model using the training dataset. To that end, the model trainer 354 may include computer program instructions that may obtain a training dataset, pre-process the training dataset, and train the predictive model 352 using the training data, such as using one or more of supervised or unsupervised training techniques. In an example of training using a supervised training technique, the model trainer 354 may obtain a labeled training dataset. The labeling may be done by a human based on past observations. For example, the labeled dataset may have a set of healthcare data inputs, such as data passively collected by wearable sensors, invisible sensors, etc., data collected by active patient engagement with an application running on a patient user device, and / or data of test results (e.g., blood tests). These inputs may be associated with observed outputs, such as, for example, if a patient associated with a first set of inputs develops an adverse reaction, the data may be human labeled as associated with the adverse reaction. Similarly, if a patient associated with a second set of inputs does not develop an adverse reaction, the corresponding data may be human labeled as not associated with the adverse reaction.

[0063] Thus, using the labeled dataset (e.g., ground truth of the outputs is provided along with the inputs), the model trainer 354 may train the predictive model 352. However, it should be understood that the supervised training approach is just one approach and should not be considered limiting. The model trainer 354 may use other approaches, such as unsupervised training approaches, to train the predictive model 352.

[0064] Although the predictive model 352 is described herein as a machine learning model, it should be understood that the predictive model 352 may include a statistical model. In the case of a statistical model, the model trainer 354 may act as a model generator to generate the statistical model. The statistical model may be used to predict which combinations of input variables (e.g., healthcare data from various sources) are more likely to result in a "cytopenia" output and which combinations of input variables are more likely to result in a "no cytopenia" output.

[0065] It should be appreciated that the model trainer 354 may continually train the predictive model 352. For example, if ground truth is available for a prediction (e.g., the ground truth may indicate whether a prediction was accurate or inaccurate), the model trainer 354 may use such accurate or inaccurate predictions to continually train and improve the predictive model 352.

[0066] The model deployer 356 may be a software module that uses the trained predictive model 352 to predict the likelihood of a side effect (e.g., cytopenia) from received input data. For example, new healthcare data may be received for a patient undergoing an oncology treatment regimen (e.g., CDK inhibitor treatment regimen, PARP inhibitor treatment regimen). The new healthcare data may include, for example, passively collected data from the wearable device 302a, data collected by patient engagement from the patient user device 302b, data collected from other sensors 302c, data collected from biofluid monitoring data source 340, etc. The healthcare data may include, for example, heart rate, skin temperature, blood pressure, blood oxygen saturation, etc. When such healthcare data is provided to the trained predictive model 352, the predictive model may output a likelihood of a side effect. The likelihood may be expressed as a probabilistic output, for example, 85% likely to develop cytopenia or 15% likely not to develop cytopenia. Alternatively or additionally, the likelihood may be expressed as a binary classification, e.g., "likely to develop cytopenia" and "likely not to develop cytopenia." The binary classification may be determined by the underlying probabilistic output and may use a threshold. For example, the binary classification may output "likely to develop cytopenia" when the probabilistic output crosses a "55% likely to develop cytopenia" threshold. The threshold may be adjusted as the predictive model 352 is continually trained and refined.

[0067] The communication facilitator 358 may generate one or more notifications based on the trained predictive model 352 indicating a higher likelihood of a side effect. The notifications may be provided to the physician dashboard 342. In some cases, the notifications may provide a probabilistic likelihood that the patient will develop the side effect. In other cases, the notifications may be a binary output of whether the patient is likely to develop the side effect or not. The dashboard application 342 may show a view of the patient's profile / health data 381, and the notifications may be presented within the view. In addition to the notifications to the physician dashboard 342, the communication facilitator 358 may transmit another notification to the healthcare application 332 executing on the patient user device 302b. The notification to the patient may not necessarily indicate a likelihood of a side effect, but may simply indicate that the physician is following up on the healthcare issue. One or more of these notifications may also establish bidirectional connectivity between the patient and the physician, either through the healthcare application 332 itself or through other components within the operating environment 300.

[0068] For example, if the predictive model 362 determines that the patient is likely to develop an adverse event (e.g., cytopenia), the communication facilitator 358 may transmit a first alert notification to the patient (e.g., to be displayed in the healthcare application on the patient user device 302b) and a second alert notification to the physician (e.g., to be displayed in the dashboard application 342 on the physician user device 308). One or more of these alerts may have a communication prompt. For example, the first alert to the patient may have the prompt "Send message to your physician." The second alert to the physician may be "Contact Patient A, may be developing cytopenia." In response to these prompts, an asynchronous (e.g., through a text message exchange) or synchronous (e.g., through a voice / video chat) communication channel may be opened between the healthcare application 332 and the dashboard application 342. In addition to this bidirectional connectivity, the physician may be able to perform other actions, such as prescribing medication, providing educational materials, and / or any other type of patient care action. As explained above, the bidirectional connectivity does not necessarily have to be between the healthcare application 332 and the dashboard application 342, but can be provided by any other type of component (eg, a phone call).

[0069] Based on the output of the predictive model 352 and subsequent notification to the physician dashboard application 342, the physician may decide on a clinical intervention, such as prescribing a medication, recommending a change in diet or activity level to the patient, etc. In general, the output of the predictive model 352 may provide clinical decision support.

[0070] In some embodiments, the model trainer 354 may generate a model (e.g., train a predictive model 352 or generate an analytical model) for an individual patient. For example, the model trainer 354 may obtain longitudinal data for an individual patient and then establish a baseline as the corresponding trained predictive model 352. The baseline may include, for example, normal levels of physical activity, biometric data (e.g., blood oxygen saturation, etc.), symptoms reported by the patient (e.g., “feeling tired”), and / or biofuel analytical data, such as blood test data (e.g., normal white blood cell count). A combination of normal levels of these attributes may be established as the baseline in the trained predictive model 352 or generated analytical model. During the deployment phase, newly received healthcare data may be compared to the baseline to determine whether there is a significant amount of deviation from the established baseline.

[0071] In some embodiments, the model trainer 354 may generate a population-level baseline. For example, the model trainer 354 may obtain longitudinal data for a population of patients having certain criteria, such as age, sex, geographic location, ethnicity, etc. Based on the collected data, the model trainer 354 may establish a population-level baseline within the trained predictive model 352 (and / or statistical model). The model deployer 346 may then use the population-level baseline to determine whether an individual patient's condition was significantly deviating from normal levels and therefore, that the patient may have been likely to develop an adverse event.

[0072] The dashboard application 342 may be displayed on a physician user device 308, which may be any type of user device that may be used by a physician. Non-limiting examples of physician user devices 308 may include a mobile phone (e.g., a smartphone), a tablet computer, a laptop computer, a desktop computer, and the like. The dashboard application 342 may be an installed standalone application or a web-based application accessible through a browser. The dashboard application 342 may show disease progression for an individual patient. For example, the dashboard application 342 may show charts showing how vital data (e.g., blood oxygen saturation) has changed over time. The dashboard application may also show other aspects of the patient's health, such as stress and anxiety levels. The dashboard application 342 may further show medications prescribed for the patient. In general, the dashboard application 342 may show any type of clinical data, as well as notifications for patients being monitored within the treatment and operating environment 300.

[0073] 4 shows a flow diagram of an exemplary method 400 of training a predictive model for predicting side effects in patients undergoing a CDK treatment regimen, according to some embodiments of the present disclosure. The exemplary method 400 may be performed by one or more computing devices (e.g., computing device 200 as used within operating environment 100). It should be understood that the steps of method 400 shown in FIG. 4 and described herein are merely illustrative, and methods with additional, alternative, or fewer steps should be considered within the scope of the present disclosure.

[0074] In step 402, a long-term training input dataset may be obtained. The long-term training dataset may include health care data for a population of patients who have undergone oncology treatment (e.g., CDK inhibitor treatment, PARP inhibitor treatment, etc.). The health care data may include, for example, data collected through patient engagement in an application (prescription software) installed on a patient device, passively collected biometric data from wearables (e.g., temperature, blood oxygen saturation, heart rate, blood pressure), and data from an integrated biofluid testing system (e.g., home testing kit) for patients undergoing oncology treatment. In addition, the long-term training input dataset may include other information such as patient demographic information, medical history, family history, and / or any other health care attributes that may affect oncology treatment. The dataset obtained in this step may be used as an input for training a predictive model.

[0075] In step 404, a labeling dataset may be obtained. The labeling dataset may generally indicate whether a patient associated with the longitudinal training input dataset has actually developed an adverse event related to oncology treatment. Thus, the labeling dataset may come from a variety of sources. For example, the labeling dataset may be sourced from a patient's electronic medical record (e.g., EHR 381 shown in FIG. 3). In some embodiments, the labeling dataset obtained in step 404 may be used to manually label the longitudinal training input dataset obtained in step 402.

[0076] Thus, the combination of the long-term training input dataset and the labeling dataset may provide a labeled training dataset for training the predictive model in step 406. Using the labeled training dataset, the predictive model may be trained using a supervised training approach. For example, each training iteration may generate an output that may be compared to the predicted output (e.g., as indicated by the label), and backpropagation techniques may be used to refine the predictive model so that it produces an output closer to the expected output. Some non-limiting examples of predictive models may include a regression model, a gradient boosting regression model, a logistic regression model, a random forest regression model, an ensemble model, a classification model, a deep learning neural network, a recurrent neural network for deep learning, or a convolutional neural network for deep learning.

[0077] Such techniques for training a predictive model are merely examples, and other techniques should also be considered within the scope of the present disclosure. For example, the predictive model may be trained using an unsupervised training technique. In other examples, the predictive model may be a statistical model, and step 406 may establish the statistical model using the acquired data set. Thus, any type of data analysis for generating a predictive model or for establishing a statistical model should be considered within the scope of the present disclosure.

[0078] 5 shows a flow diagram of an exemplary method 500 of using a trained predictive model to predict side effects in patients undergoing oncology therapy (e.g., CDK inhibitor therapy, PARP inhibitor therapy, etc.) according to some embodiments of the present disclosure. The exemplary method 500 may be performed by one or more computing devices (e.g., computing device 200 as used within operating environment 100). It should be understood that the steps of method 500 shown in FIG. 5 and described herein are merely illustrative, and methods with additional, alternative, or fewer steps should be considered within the scope of the present disclosure.

[0079] In step 502, health care data about a patient undergoing oncology treatment may be received. As a guide for oncology treatment, the patient may be provided with prescription software, for example, a health care application installed on a smartphone. The patient may input symptoms and / or medically relevant data into the health care application. The patient may also be provided with a wearable device (e.g., a smart watch). The wearable device may passively capture data such as movement, blood oxygen saturation, blood pressure, heart rate, body temperature, and the like. Additionally, the health care data may include biofluid analysis data from an integrated biofluid testing system, such as a home biofluid testing kit and a clinical testing system. Thus, health care data from multiple sources may be used as input to the trained predictive model.

[0080] In step 504, the received data may be fed to a trained predictive model. The predictive model may have been trained using the steps of method 400. It should also be understood that the trained predictive model includes any type of established statistical model. Some non-limiting examples of predictive models may include a regression model, a gradient boosting regression model, a logistic regression model, a random forest regression model, an ensemble model, a classification model, a deep learning neural network, a recurrent neural network for deep learning, or a convolutional neural network for deep learning. In some cases, a statistical model may be used, in which case step 504 may include comparing statistics (e.g., z-statistics) to determine whether the received data is significantly close to a possible outcome (e.g., an outcome indicative of an adverse effect such as cytopenia). However, it should be understood that these are merely examples and other predictive / statistical models should be considered within the scope of this disclosure.

[0081] In step 506, the predictive model (or statistical model) generates an output indicative of the likelihood of an adverse event, such as a cytopenia. The likelihood of the adverse event may indicate the probability that the inputs provided are associated with the adverse event, and a corresponding probability that they are not associated with the adverse event. For example, the output may be a 90% probability of cytopenia, and a 10% probability of no cytopenia. In other embodiments, the output may be binary: for example, if the probabilistic likelihood exceeds a certain threshold, the output is likely to be cytopenia, otherwise it is unlikely to be cytopenia.

[0082] In step 508, one or more notifications may be triggered based on the output of the predictive model. For example, if the predictive model generates a higher probability of cytopenia, a notification may be triggered to a physician's dashboard. The notification may indicate that a certain patient is likely to develop cytopenia. This notification may provide clinical decision support to the physician in planning clinical intervention. For example, the physician may prescribe a drug for patients with a higher probability of cytopenia in combination with a lower dose of oncology therapy (e.g., a lower dose of a CDK inhibitor). For patients with some probability of cytopenia, the physician may recommend diet and lifestyle changes without necessarily lowering the dose of oncology therapy. In addition to physician notifications, patient notifications may also be generated. Patient notifications may include the physician contacting the patient with important clinical information.

[0083] It will be understood by those skilled in the art that the present disclosure may be embodied in other specific forms without departing from its spirit and essential characteristics.The presently disclosed embodiments are therefore considered in all respects to be illustrative and not limited.The scope of the present disclosure is indicated by the appended claims, rather than the foregoing description, and all changes that come within the meaning and scope and equivalents are intended to be embraced therein.

[0084] It should be noted that the terms "including" and "comprising" are to be construed to mean "including, but not limited to." Unless otherwise expressly recited in the claim, "a" is to be construed as "at least one," and "the," "the," etc. are to be construed as "at least one," "at least one of," etc. Furthermore, it is Applicant's intent that only those claims which include the language "means for" or "step for" shall be construed under 35 U.S.C. 112(f). Any claim which does not expressly include the language "means for" or "step for" shall not be construed under 35 U.S.C. 112(f).

Claims

1. 1. A computer-implemented method comprising: acquiring first health data including symptoms of a patient receiving cyclin dependent kinase (CDK) inhibitor treatment; acquiring second health data comprising an analysis of a biological fluid sample collected from the patient; deploying a machine learning model on the first health data and the second health data to predict whether the patient will develop a side effect associated with the CDK inhibitor treatment; In response to the machine learning model predicting that the patient is likely to develop an adverse event, generating a message to be transmitted to a physician dashboard to trigger a notification on the physician dashboard; A computer-implemented method comprising:

2. 10. The computer-implemented method of claim 1, further comprising training a machine learning model using a supervised approach by passing labeled data of a patient cohort through the model.

3. 2. The computer-implemented method of claim 1, wherein the machine learning model comprises at least one of a regression model, a gradient boosting regression model, a logistic regression model, a random forest regression model, an ensemble model, a classification model, a deep learning neural network, a recurrent neural network for deep learning, or a convolutional neural network for deep learning.

4. 10. The computer-implemented method of claim 1, wherein the first health data is based on active input of the symptoms by a patient into a healthcare application executing on a client device associated with the patient.

5. 2. The computer-implemented method of claim 1, wherein the first health data is based on data passively collected by a wearable device worn by the patient.

6. The computer-implemented method of claim 1 , wherein the second health data is obtained from an at-home biological fluid collection kit.

7. The computer-implemented method of claim 1 , wherein the second health data is obtained from a laboratory system.

8. The computer-implemented method of claim 1 , wherein triggering the notification on the physician dashboard comprises providing the notification to an electronic health record (EHR) system.

9. 2. The computer-implemented method of claim 1, wherein the message to be transmitted to the physician dashboard includes at least one of an instruction that the physician should contact the patient, an instruction that a prescribed medication dosage should be adjusted, or an instruction that the patient should be hospitalized.

10. 1. A computer-implemented method comprising: acquiring first health data including symptoms of a patient receiving cyclin dependent kinase (CDK) inhibitor treatment; acquiring second health data comprising an analysis of a biological fluid sample collected from the patient; deploying a machine learning model on the first health data and the second health data to predict whether the patient will develop a side effect associated with the CDK inhibitor treatment; In response to the machine learning model predicting that the patient is likely to develop an adverse event, generating a message to be transmitted to a healthcare application executing on a client device associated with the patient to trigger a notification on the healthcare application; A computer-implemented method comprising:

11. 11. The computer-implemented method of claim 10, further comprising training the machine learning model using a supervised approach by passing labeled data of a patient cohort through the model.

12. 11. The computer-implemented method of claim 10, wherein the machine learning model comprises at least one of a regression model, a gradient boosting regression model, a logistic regression model, a random forest regression model, an ensemble model, a classification model, a deep learning neural network, a recurrent neural network for deep learning, or a convolutional neural network for deep learning.

13. 11. The computer-implemented method of claim 10, wherein the message to be transmitted includes at least one of an instruction that the patient should contact the physician, an instruction that the patient should pick up medication at a pharmacy, or an instruction that the patient should contact emergency services.

14. The computer-implemented method of claim 10 , further comprising establishing bidirectional connectivity between the patient and a physician based on the notification on the healthcare application.

15. The computer-implemented method of claim 10 , wherein the side effect comprises cytopenia.

16. prompting the patient to input the symptoms into the healthcare application executing on the client device associated with the patient; and obtaining the symptom as the first health data from the healthcare application.

17. triggering a wearable device worn by the patient to passively collect biometric data of the patient; acquiring the biological data passively collected by the wearable device as the first health data; The computer-implemented method of claim 10 further comprising:

18. 1. A system comprising: one or more processors; and a non-transitory storage medium storing computer program instructions that, when executed by the one or more processors, cause the system to perform operations, the operations including: Obtaining first health data including a symptom of a patient receiving cyclin dependent kinase (CDK) inhibitor treatment; acquiring second health data comprising an analysis of a biological fluid sample collected from the patient; deploying a machine learning model on the first health data and the second health data to predict whether the patient will develop a side effect associated with the CDK inhibitor treatment; triggering one or more notifications in response to the machine learning model predicting that the patient is likely to experience an adverse event; and Including, the system.

19. 20. The system of claim 18, wherein the one or more notifications include at least one patient notification on a healthcare application running on a client device associated with the patient and a notification on a physician dashboard.

20. The operation includes: training the machine learning model using a supervised approach by passing labeled data of a patient cohort through the model; The machine learning model includes at least one of a regression model, a gradient boosting regression model, a logistic regression model, a random forest regression model, an ensemble model, a classification model, a deep learning neural network, a recurrent neural network for deep learning, or a convolutional neural network for deep learning.

20. The system of claim 18.

Images