A wearable guide to detecting cytokine release syndrome

Abstract

The embodiments disclosed herein may provide digital medical support to predict and mitigate side effects of bispecific antibody therapy (e.g., Pfizer's erlanatamab) for myeloma patients. Side effects may include cytokine release syndrome (CRS), infections (e.g., sepsis), neurotoxicity (e.g., peripheral neuropathy), cytopenias (e.g., neutropenia), and the like. These side effects may be predicted based on passive collection of data from patient wearables, patient-entered data on healthcare applications, and other data such as blood test data. Trained machine learning models may be used to predict side effects. Because side effects may be predicted prior to their onset, preventative interventions may be feasible to improve healthcare outcomes for myeloma patients.

Description

[Technical field]

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

[0002] The subject matter presented herein is directed to systems and methods for monitoring myeloma treatment, and in particular, for monitoring side effects, such as cytokine release syndrome, associated with myeloma treatment. [Background technology]

[0003] Myeloma, also called multiple myeloma, is a cancer of plasma cells. Cancerous plasma cells can grow rapidly and crowd out normal cells such as red blood cells, platelets, and other white blood cells. Forms of myeloma treatment can include bispecific antibodies. Bispecific antibodies can engage two different targets at once: one arm of the antibody can directly bind to a specific antigen on the cancer cells, and the other arm can activate and attract the patient's own T cells from the immune system to kill the cancer cells. However, bispecific antibody treatment can have side effects: patients can have the potential to develop cytokine release syndrome (CRS), typically within 48 hours after the start of bispecific antibody treatment, and can also develop other pathologies such as infections (e.g., sepsis), neurotoxicity (e.g., peripheral neuropathy), and blood cytopenias (e.g., neutropenia) after bispecific antibody treatment.

[0004] Traditional side effect management for bispecific antibody therapy is wasteful and inadequate. For example, traditional CRS management involves a minimum of 48 hours of hospitalization after a session of bispecific antibody therapy. However, clinical trials of bispecific antibody therapy - Pfizer's erlanatamab - have found that only 50-70% of patients may experience any CRS. More specifically, about 25-35% may experience grade 1 CRS, 25-35% may experience grade 2 CRS, and 30-50% may not experience any CRS at all. Only grade 2 CRS, i.e., only 25-35% of patients, may require hospital-level intervention. Traditionally, all patients are hospitalized to observe any development of CRS. Thus, hospitalization of 65-75% of patients, i.e., 25-35% of patients who develop grade 1 CRS that simply requires minor intervention, and 30-50% who do not develop any CRS, is wasteful.

[0005] Moreover, traditional side effect management for other conditions such as infections, neurotoxicity, and cytopenias is based on sporadic clinical encounters with limited patient-physician face-time. Sporadic clinical encounters often provide an incomplete picture of a patient's condition based on biased information from the patient (e.g., recall bias). Thus, traditional clinical encounters do not adequately detect risks in a timely manner. For example, myeloma patients - especially after bispecific antibody treatment - may have a weakened immune system that may predispose them to infections such as sepsis. Infections have been found to be a major cause of death, especially for patients with triple class refractory multiple myeloma. Although early interventions can be effective in mitigating infections in general, sporadic clinical encounters may be insufficient to detect the onset of infections and guide such early interventions.

[0006] Neurotoxicity and associated peripheral neuropathy may develop from other myeloma drugs, e.g., proteasome inhibitors, immunomodulatory agents (IMiDs), that are typically taken prior to bispecific antibody therapy. Because the onset of these diseases is not always early and rapid, there may not be enough clinical encounters for patients to report relatively milder symptoms to their physicians. Even if there are multiple clinical encounters, patients may not always report these relatively milder symptoms (e.g., due to recall bias). Cytopenias may occur throughout the bispecific antibody treatment regimen. Cytopenias impose an additional burden on patients, as they require frequent blood tests for their identification. Frequent blood tests are typically not convenient for myeloma patients, which may require multiple visits to the laboratory. Scattered clinical encounters and scattered blood tests are insufficient for timely detection of cytopenias. Summary of the Invention [Problem to be solved by the invention]

[0007] In some embodiments, the present disclosure relates to a digital medical guide for bispecific antibody therapy for myeloma. The present disclosure further relates to predicting side effects associated with bispecific antibody therapy and to proactively managing predicted side effects. [Means for solving the problem]

[0008] For example, a machine learning model may be used to predict the likelihood that a patient will develop CRS after bispecific antibody treatment (e.g., Pfizer's erlanatamab). To that end, health care data from the patient may be collected in association with the bispecific antibody treatment - either actively by the patient entering the data into an application, and / or passively by the device supplementing the health care data. Additional data, such as blood test data, may also be collected. The data collection period may begin at a predefined time (e.g., several days prior) prior to treatment. Using the collected data, the machine learning model may output the likelihood that the patient will develop CRS, and a notification may be generated for the physician's dashboard. The notification may provide clinical decision support, whether the patient should be hospitalized or may be discharged for home monitoring based on the likelihood of developing CRS.

[0009] Additionally or alternatively, other side effects associated with bispecific antibody therapy can be predicted and proactively managed. Patients being monitored at home can actively input health care data into a health care application (e.g., installed on a smartphone). Other devices, such as wearables and invisible sensors, can passively collect health care data. Additionally, home blood monitoring systems (e.g., blood collection kits mailed to the patient's home) can provide blood-related data. Using these different types of collected data, machine learning models can predict whether a patient is likely to develop a side effect, such as CRS, neurotoxicity, or cytopenia. Based on the prediction, one or more alert notifications can be sent to a patient interface (e.g., to encourage the patient to contact their physician) and / or a physician interface (e.g., to encourage the physician to contact the patient).

[0010] In one embodiment, a computer-implemented method may be provided. The method may include: acquiring first health data input by a patient on a predetermined application executed by a patient computing device before treatment; acquiring second health data passively collected by a predetermined wearable device before treatment; deploying a machine learning model on the first health data and the second health data to determine whether the patient is likely to experience cytokine release syndrome after treatment; and triggering a notification on a physician dashboard in response to determining that the patient is likely to experience cytokine release syndrome.

[0011] In another embodiment, another computer-implemented method may be provided. The method may include: acquiring first health data input by a patient on a predetermined application executed by a patient computing device after treatment; acquiring second health data passively collected by a predetermined wearable device after treatment; deploying a machine learning model on the first health data and the second health data to determine whether the patient is likely to experience a poor health condition after treatment; and triggering a notification on a physician dashboard in response to determining that the patient is likely to experience a poor health condition.

[0012] 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 input by a patient undergoing bispecific antibody treatment on a predetermined application executed by a patient computing device; acquiring second health data passively collected by a predetermined wearable device worn by the patient; deploying a machine learning model on the first health data and the second health data to determine whether the patient is likely to experience a poor health condition after the treatment; and triggering one or more notifications in response to determining that the patient is likely to experience a poor health condition.

[0013] 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]

[0014] [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 CRS prediction, 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 CRS prediction, according to some embodiments of the present disclosure. [Figure 6] FIG. 1 is a flow diagram of an illustrative method for generating a model for baseline health behaviors, according to some embodiments of the present disclosure. [Figure 7] FIG. 1 is a flow diagram of an illustrative method for comparing recent healthcare data with baseline health behaviors, according to some embodiments of the present disclosure. [Figure 8A] FIG. 1 shows an exemplary process flow for CRS prediction for bispecific antibody therapy, according to some embodiments of the present disclosure. [Figure 8B] FIG. 1 shows an illustrative process flow for home monitoring of a patient undergoing bispecific antibody therapy according to some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] 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.

[0016] The embodiments disclosed herein may provide digital medical support to predict and mitigate side effects of bispecific antibody therapy (e.g., Pfizer's erlanatamab) for myeloma patients. Side effects may include cytokine release syndrome (CRS), infections (e.g., sepsis), neurotoxicity (e.g., peripheral neuropathy), cytopenias (e.g., neutropenia), and the like. These side effects may be predicted based on passive collection of data from patient wearables and / or invisibles, patient-entered data on healthcare applications, and other data such as blood test data. Trained machine learning models may be used to predict side effects. Because side effects may be predicted prior to their onset, preventative interventions may be feasible to improve healthcare outcomes for myeloma patients.

[0017] Prediction can be used for both hospital observation and home monitoring environments. For example, health care data collected leading up to and around the administration of bispecific antibody therapy can be used to predict whether a patient may be likely to develop CRS. Prediction can support clinical decisions regarding whether a patient may be discharged for home monitoring (e.g., due to a low probability of CRS) or whether the patient should remain in the hospital for observation (e.g., due to a high probability of CRS). During home monitoring, predictions of one or more medical conditions can be made based on passively collected data, patient-entered data, and / or other data such as blood test data. If a bad condition is predicted, an alert notification can be triggered to the patient and / or physician for timely intervention to mitigate the bad condition.

[0018] 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.

[0019] As shown, the operating environment 100 may include patient user devices 102a-102n (collectively or commonly referred to as devices 102), blood monitoring devices 110, a server 106, an electronic health record (EHR) system 104, a network 110, 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 110.

[0020] The patient 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 smart watches 102a, mobile devices 102b (e.g., smartphones), other smart sensors 102c (e.g., smart rings, invisible sensors such as motion sensors, etc.), fitness trackers 102d, and other patient user devices 102n (e.g., tablets, laptop computers, desktop computers, smart speakers, smart home systems, etc.). The patient user devices 102 may either passively collect or actively prompt the patient to enter data associated with the management of side effects associated with bispecific antibody therapy.

[0021] 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.

[0022] 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, such as an electronic patient-reported outcome (ePRO) application, may be installed. The healthcare application may prompt the patient to input health-related data. 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 time point. 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 CRS, cytopenia, neutropenia, 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 the established baseline behavior. In response, the healthcare application may further enable the patient to communicate with the physician synchronously or asynchronously.

[0023] 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 110.

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

[0025] Network 110 may include any type of communication network. For example, network 110 may include a packet switching network supporting protocols such as TCP / IP. Network 110 may also include a circuit switching network supporting both wired and wireless telephony. Thus, network 110 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 network 110 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 network 110, and any type of communication linkage between different components of operating environment 100 should be considered within the scope of this disclosure.

[0026] The server 106 may include any type of computing device that may 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 CRS progression, e.g., whether a patient receiving bispecific antibody therapy will develop CRS and / or how likely a patient receiving bispecific antibody therapy is to develop CRS. 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. The same predictive model or another predictive model may be trained to determine whether a patient will develop other adverse health conditions.

[0027] 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., CRS, cytopenia, neutropenia, etc.) and / or that the patient's health behavior has significantly deviated from the baseline behavior.

[0028] 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., myeloma), prescribed 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).

[0029] 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 blood monitoring device 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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."

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] The operating environment 300 may be used for continuous or near-continuous digital monitoring of a patient receiving bispecific antibody therapy (e.g., Pfizer's erlanatamab) and triggering alert notifications to the patient and / or physician as needed. Moreover, the operating environment 300 may provide seamless and continuous connectivity between the patient and physician. This continuous or near-continuous monitoring may enable preventative management of side effects associated with bispecific antibody therapy, and machine learning models may predict the onset of one or more pathologies, thereby facilitating early intervention by a physician for those conditions. The operating environment 300 may further be used for clinical decision support, for example, whether to discharge a patient for home monitoring or whether to keep the patient in a hospital environment for observation after a bispecific antibody treatment session. 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 and other sources (e.g., blood monitoring data source 340) may be stored in storage 370 (e.g., personal records 380). Analysis components (e.g., CRS predictor 350, disease progression tracker 360) may use the stored data and other data to predict CRS and / or track the progression of side effects (e.g., infections, neurotoxicity, cytopenias, etc.) associated with bispecific antibody therapy for myeloma. Based on the analysis, alert notifications 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.

[0041] 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 one or more of the CRS predictor 350, the disease progression tracker 360, 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.

[0042] 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).

[0043] In other words, the sensor 324 may passively collect healthcare data without the patient's active involvement. For example, the sensor 324 may monitor the patient's biometric data and / or physical movements because the sensor 324 is within 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.

[0044] 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., how the patient is feeling at a particular point in time).

[0045] As an example, the healthcare application 332 may be used to gather further information regarding predictions based on data collected by the sensor 324 of the wearable device. For example, using passively collected data, the disease progression tracker 360 may predict the onset of side effects of bispecific antibody therapy. For example, the sensor 324 of the wearable device 302a may measure less body movement compared to an established baseline, and the disease progression tracker 360 may predict the onset of neurotoxicity. In response to this prediction, an alert notification may be sent (e.g., by the communication facilitator 368) 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 sensor 324 of the wearable device 302a 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 "extremely dizzy," "moderately dizzy," or "not dizzy." These are just a few examples of alert notifications to the patient, and other types of alert notifications should be considered within the scope of this disclosure.

[0046] 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 how they are feeling each morning, afternoon, and evening. 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, experienced pain levels, stress levels, anxiety levels, time of taking prescribed medications, athletic activity (if not captured by the wearable device 302a), observed side effects of bispecific antibody therapy, and / or any other type of healthcare data.

[0047] In addition to the alert notification, 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 one or more of the CRS predictor communication facilitator 358 and the disease progression tracker 360 communication facilitator 368. The bidirectional connectivity may allow the patient to establish synchronous (e.g., voice or video call) or asynchronous (e.g., message exchange) with the physician at any time. The bidirectional connectivity may be initiated in response to an alert notification. For example, the disease progression tracker 360 may predict the onset of a cytopenia and the corresponding communication facilitator 368 may have generated 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 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 disease progression tracker 360. The CBT-based materials may be in the form of audio, video, and / or text and may encourage the patient to make healthier choices regarding diet, rest and exercise, stress management, and / or any other metrics associated with maintaining a good quality of life while receiving bispecific antibody therapy.

[0048] 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.

[0049] 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).

[0050] 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 the bispecific antibody treatment 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.

[0051] The blood monitoring data source 340 can be any type of blood analysis device or system. For example, the blood monitoring data source 340 can include a home blood collection kit. The home blood collection kit can be mailed to the patient's home and used by the patient to collect a blood specimen to be sent to a laboratory. The laboratory can then perform a blood analysis (e.g., determine a white blood cell count) 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 blood analysis capabilities in combination with the patient user device 302b, for example, an analysis component in the kit can connect to the patient user device 302b to provide the measured data.

[0052] Blood monitoring data sources 340 may further include other types of sources, such as a laboratory, a doctor's office, and / or any type of equipment and / or facility for collecting and analyzing blood samples. Regardless of its type, blood monitoring data sources 340 may provide measured data to other components in operating environment 300 (e.g., over network 310).

[0053] 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 blood 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.

[0054] Data received from patient-facing devices (e.g., wearable devices 302a, patient user devices 302b, other sensors 302c, etc.) and other sources (e.g., blood 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.

[0055] 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.

[0056] 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 385.

[0057] 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, test results, and / or any other type of health care data about the patient. For example, profile / health care data 381 may include information regarding a treatment regimen using a bispecific antibody and any observed side effects upon administering the bispecific antibody. 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 health care provider (e.g., a hospital) and operating environment 300 may obtain the data from the health care provider.

[0058] 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).

[0059] 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 how they were feeling at a particular point in time (e.g., "fatigued," "depressed," "good," etc.). As another example, the patient-entered data 383 may include the patient's response to various alert notifications provided by the healthcare application 332. The patient-entered data 383 may further include other biometric data that is 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., that are captured by devices (e.g., external blood pressure monitors) that operate 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.

[0060] 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 may include data from the blood 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 data points within the operating environment 300 should be considered as 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 CRS predictor 350 and / or the disease progression tracker 360).

[0061] 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 bispecific antibody therapy. The past event log 385 may also be time-stamped such 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.

[0062] The analytical components (e.g., CRS predictor 350 and disease progression tracker 360) may use the personal 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 CRS and / or the onset of other side effects associated with bispecific antibody therapy.

[0063] The CRS predictor 350 may predict the likelihood of CRS in patients receiving bispecific antibody therapy. Such predictions 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 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.

[0064] 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, e.g., if a patient associated with a first set of inputs develops CRS, the data may be human labeled as associated with CRS. Similarly, if the patient associated with the second set of inputs did not develop CRS, the corresponding data may be human labeled as not associated with CRS.

[0065] 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 model.

[0066] 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 “CRS” output and which combinations of input variables are more likely to result in a “no CRS” output.

[0067] 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.

[0068] The model deployer 356 may be a software module that uses the trained predictive model 352 to predict the likelihood of CRS from received input data. For example, new healthcare data may be received for a patient undergoing bispecific antibody therapy. 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 blood monitoring data sources 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 CRS. The likelihood may be expressed as a probabilistic output, for example, 85% likely to develop CRS or 15% likely not to develop CRS. Alternatively or additionally, the likelihood may be expressed as a binary classification, for example, "likely to develop CRS" and "not likely to develop CRS." 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 CRS" when the probabilistic output exceeds a "55% likely to develop CRS" threshold. The threshold may be adjusted as the predictive model 352 is continually trained and refined.

[0069] The communication facilitator 358 may generate one or more notifications based on the trained predictive model 352 indicating a higher likelihood of CRS. 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 CRS. In other cases, the notifications may be a binary output of whether the patient is likely to develop CRS 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 running on the patient user device 302b. The notification to the patient may not necessarily indicate a likelihood of CRS, but may simply indicate that the physician is following up on the healthcare issue. One or more of these notifications may also establish two-way connectivity between the patient and the physician.

[0070] Based on the output of the predictive model 352 and subsequent notification to the physician dashboard application 342, the physician may determine whether the patient may be discharged for home monitoring or should remain in the hospital for observation. For example, the physician may determine that patients who are more likely to develop CRS should remain in the hospital and patients who are less likely to develop CRS may be discharged for home monitoring.

[0071] Home monitoring may be driven by a disease progression tracker 360, which may be another type of analysis provided within the operating environment 360. In general, the disease progression tracker may use a predictive model 362 (and / or a statistical model) to determine whether a home monitored patient may develop an adverse event such as CRS, infection, neurotoxicity, cytopenia, etc. To that end, the disease progression tracker 360 may use a model trainer 364 to train the predictive model 362, a model deployer 366 to deploy the predictive model 362, and a communication facilitator 368 to generate one or more notifications and / or establish bidirectional connectivity based on the output of the predictive model 362.

[0072] The model trainer 364 may include computer program instructions that may retrieve longitudinal data (e.g., profile health data 381, past event log 385, etc.) from storage. This longitudinal data may be used to train the predictive model 362 (and / or generate an analytical model). It should be understood that the predictive model may include any type of machine learning model, such as, 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. The model trainer 364 may use a supervised training method, for example, with labeled output data to train the predictive model 362. However, it should be understood that unsupervised techniques may also be used to complement supervised training techniques.

[0073] In some embodiments, the model generator 364 may generate a model (e.g., train a predictive model or generate an analytical model) for an individual patient. For example, the model generator 364 may obtain longitudinal data for an individual patient and then establish a baseline as the corresponding trained predictive model 362. The baseline may include, for example, normal levels of physical activity, biometric data (e.g., blood oxygen saturation, etc.), and mood reported by the patient (e.g., “feeling tired”). Thus, a combination of normal levels of these attributes may be established as the baseline in the trained predictive model 362 or generated analytical model. In 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.

[0074] In some embodiments, the model generator 364 may generate a population-level baseline. For example, the model generator 364 may obtain longitudinal data for a population of patients having certain criteria, such as age, sex, geographic location, ethnicity, etc. Analyzing the collected data, the model generator 364 may establish a population-level baseline within the trained predictive model 362 (and / or statistical model). The model deployer 366 may then use the population-level baseline to determine whether an individual patient's condition has significantly deviated from normal levels.

[0075] The communication facilitator 368 may facilitate communication between the patient and the patient, for example, by using the healthcare application 332 and the dashboard application 342. For example, if the analytical model 362 determines that the state of the disease condition has significantly deviated from normal and that the patient may be about to develop an adverse event (e.g., an infection), the communication facilitator 368 may transmit a first alert notification to the patient (e.g., to be displayed in the healthcare application 332 of the patient user device 302b) and a second alert notification to the physician (e.g., to be displayed in the dashboard application 342 of 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 a prompt "send message to your physician". The second alert to the physician may be "contact Patient A, may be developing an infection". In response to these prompts, an asynchronous (e.g., through text message exchange) or synchronous (e.g., through audio / 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 medications, providing educational material, and / or any other type of patient care action.

[0076] 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.

[0077] 4 shows a flow diagram of an exemplary method 400 of training a predictive model for CRS prediction, 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.

[0078] In step 802, 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 been receiving bispecific antibody treatment. The health care data may include, for example, passively collected biometric data from wearables (e.g., temperature, blood oxygen saturation, heart rate, blood pressure), data collected through patient engagement in an application installed on the patient device, data from laboratory analyses (e.g., blood tests) leading up to and surrounding the bispecific antibody treatment session. 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 bispecific antibody treatment. The dataset obtained in this step may be used as an input to train a predictive model.

[0079] 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 CRS. 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.

[0080] 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.

[0081] 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.

[0082] 5 shows a flow diagram of an exemplary method 500 of using a trained predictive model for CRS detection, 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.

[0083] At step 502, health care data about a patient undergoing bispecific antibody therapy may be received. Prior to receiving the therapy, the patient may be provided (e.g., based on a prescription) with a wearable device (e.g., a smart watch) and / or a health care application to be installed on the patient's user device. The wearable device may passively capture data such as movement, blood oxygen saturation, blood pressure, heart rate, temperature, etc. The health care application may allow the patient to create a profile and input other data such as medical history. Additionally, the health care data may include laboratory data (e.g., blood test results). Health care data collection may begin at a predefined time prior to administration of the bispecific antibody. For example, the patient may be provided with a data collection device (e.g., a wearable, smartphone application) several days prior to administration of the bispecific antibody, and data collection may continue during and after administration.

[0084] 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 CRS). However, it should be understood that these are merely examples and other predictive / statistical models should be considered within the scope of this disclosure.

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

[0086] 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 likelihood of CRS, a notification may be triggered to a physician's dashboard. The notification may indicate that a particular patient is likely to develop CRS. The notification may provide clinical decision support to the physician to discharge the patient for home monitoring or to keep the patient in the hospital for observation. For example, the physician may recommend home monitoring for patients with a low likelihood of CRS and inpatient observation for patients with a high likelihood of CRS. In addition to physician notifications, patient notifications may also be generated. Patient notifications may include the physician contacting the patient with important clinical information.

[0087] 6 shows a flow diagram of an illustrative method 600 of training a model to establish baseline health behaviors, according to some embodiments of the present disclosure. The illustrative method 600 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 600 shown in FIG. 6 and described herein are merely illustrative, and methods with additional, alternative, or fewer steps should be considered within the scope of the present disclosure.

[0088] At step 602, health care data from one or more patients undergoing bispecific antibody therapy may be received. The health care data may include passively collected data from a wearable device (e.g., a smart watch) and / or an invisible device, and / or actively collected data through a health care application (e.g., installed on a smartphone). Passively collected data may include, for example, biometric data (e.g., heart rate) and movement data. Actively collected data may include, for example, the patient's mood state, prescription medications being taken, and / or other biometric data entered by the patient. Another type of health care data may include blood test data.

[0089] Thus, the collected data may be a time series data set showing the progression of different pathologies (e.g., infections) associated with bispecific antibody therapy. Such collection may thus be used in step 604 to train a model to establish baseline health behaviors. The baseline health behaviors may represent a normal distribution of a combination of variables, such as, for example, biological parameters, the patient's state of mind (e.g., stress and anxiety levels), the patient's activity level, blood test analysis, and / or any other attributes associated with a continuing pathology. The baseline may be established at an individual patient level and / or at a cohort population level. Non-limiting examples of trained models may include regression models, gradient boosting regression models, logistic regression models, random forest regression models, ensemble models, classification models, deep learning neural networks, recurrent neural networks for deep learning, or convolutional neural networks for deep learning.

[0090] In step 606, the trained model may be stored for comparison with future healthcare data. As healthcare data continues to be collected, such comparison may enable a determination of whether future collected healthcare data falls within the expected distribution range or deviates significantly from the expected distribution range. Significant deviations from the expected distribution range may indicate that clinical intervention may be required.

[0091] 7 shows a flow diagram of an illustrative method 700 of developing a baseline model to determine whether currently observed behavior deviates significantly from baseline disease behavior, according to some embodiments of the present disclosure. The illustrative method 700 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 700 shown in FIG. 7 and described herein are merely illustrative, and methods with additional, alternative, or fewer steps should be considered within the scope of the present disclosure.

[0092] In step 702, recent healthcare data about a patient (e.g., a patient undergoing bispecific antibody therapy) may be received. The recent healthcare data may be collected passively, e.g., through a wearable or invisible, actively, e.g., by prompting the patient to enter data into a healthcare application, and / or through other systems, such as blood collection and analysis systems. Such recent healthcare data may be collected on an ongoing basis, as the patient may be continuously monitored (e.g., home monitoring).

[0093] At step 704, the recent healthcare data may be compared to an established baseline model (e.g., a baseline model generated by method 600). This comparison may include determining whether the recent healthcare data exhibits a statistically significant deviation from the established baseline health behaviors (as indicated by the baseline model).

[0094] In step 706, one or more notifications may be triggered based on the comparison. For example, if it is determined that the patient's healthcare behavior has significantly deviated from the established healthcare behavior, an alert notification may be sent to the patient to initiate synchronous or asynchronous communication with the physician. Additionally or alternatively, another alert notification may be sent to the physician to initiate synchronous or asynchronous communication with the patient.

[0095] 8A shows a process flow 800a for CRS prediction for a bispecific antibody therapy according to some embodiments of the present disclosure. The steps of process flow 800a may be performed by any of the components of the operating environment 300 shown in FIG 3. It should be understood that the steps of process flow 800a are merely examples, and that process flows with additional, alternative, or fewer steps should also be considered within the scope of the present disclosure.

[0096] Process flow 800a may begin at step 802 when a physician prescribes a digital medicine, which the patient may download and begin using. The digital medicine may include a wearable device and / or an application for the wearable device, an application for a mobile device, etc. In step 804, the patient may use the digital medicine for a predefined time before the start of the bispecific antibody therapy. The predefined time may include, for example, days, hours, and / or any other type of time frame. In step 806, the patient may be admitted to a medical center (e.g., a hospital), vitals and blood are collected, and the bispecific therapy is administered. In step 808, the health care data is analyzed (e.g., by using a trained machine learning model) to determine a CRS risk score. In some embodiments, the risk score is determined without administering the therapy to the patient (e.g., step 806 may be skipped in some cases). If the CRS risk score is high, the patient may be admitted to a medical center for treatment, as shown in step 810. However, if the CRS risk is low, the patient may be discharged at step 812, monitored remotely via a dashboard (e.g., physician dashboard), and contacted in case of abnormal results at step 814. The home monitoring process flow 800b is shown in FIG.

[0097] 8B shows a process flow 800b for home monitoring of a patient undergoing bispecific antibody therapy, according to some embodiments of the present disclosure. The steps of process flow 800b may be performed by any of the components of the operating environment 300 shown in FIG 3. It should be understood that the steps of process flow 800b are merely examples, and that process flows with additional, alternative, or fewer steps should also be considered within the scope of the present disclosure.

[0098] Process flow 800b may begin at step 820 (as a continuation from process flow 800a) when the patient wears the sensor and continues to use the healthcare application and blood monitoring when prompted. This continued use may continually collect vitals and symptoms. If the continuously collected data indicates normal progression (e.g., using a trained baseline model), the patient may continue to schedule remote follow-ups at step 822 and subsequent therapeutic doses may also be administered. However, if abnormal progression is detected, the physician may receive a dashboard notification at step 824 indicating early signs of CRS and contact the patient for intervention. If necessary, the patient may be admitted to a medical center at step 826.

[0099] The step following step 822 may be step 828, where the patient may continue to remotely monitor vitals and anticipated side effects after the anticipated CRS risk period. Process flow 800b may return to steps 824 and 826 if abnormal medical conditions are detected in step 828. However, if medical conditions are detected to be normal in step 826, the patient may continue to perform scheduled remote follow-ups and continue treatment under the guidance of the physician in step 830. As the patient continues therapy in step 832, the physician has detailed data to track the patient's progress and titrate dosage as necessary.

[0100] 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.

[0101] 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: obtaining, prior to treatment, first health data input by a patient on a predetermined application executed by a patient computing device; Obtaining second health data passively collected by a predetermined wearable device prior to the treatment; deploying a machine learning model on the first health data and the second health data to determine whether the patient is likely to experience cytokine release syndrome following the treatment; triggering a notification on a physician dashboard in response to the determination that the patient is likely to experience the cytokine release syndrome; 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. 2. The computer-implemented method of claim 1, wherein the first health data and the second health data are received periodically for a predefined period of time prior to the treatment.

5. 10. The computer-implemented method of claim 1, wherein the determination that the patient is likely to experience the cytokine release syndrome is for a predefined period of time after receiving the treatment.

6. The method of claim 1 , wherein the first data includes at least one of a medical history, a test result, or a patient profile.

7. The method of claim 1 , wherein the second data includes at least one of temperature, heart rate, blood pressure, or oxygen saturation.

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

9. 1. A computer-implemented method comprising: After the treatment, acquiring first health data input by the patient on a predetermined application executed by the patient computing device; After the treatment, acquiring second health data passively collected by a predetermined wearable device; deploying a machine learning model on the first health data and the second health data to determine whether the patient is likely to experience an adverse health outcome following the treatment; in response to the determining that the patient is likely to experience the adverse health condition, triggering a notification on a physician dashboard; A computer-implemented method comprising:

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

11. 10. The computer-implemented method of claim 9, wherein the adverse health condition comprises at least one of cytokine release syndrome, infection, neurotoxicity, or cytopenia.

12. 10. The computer-implemented method of claim 9, 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. obtaining blood test data of the patient after the treatment; deploying the machine learning model on the first health data, the second health data, and the blood test data to determine whether the patient is likely to experience the adverse health condition; triggering the one or more notifications in response to determining that the patient is likely to experience the adverse health condition; The computer-implemented method of claim 9 , further comprising:

14. 10. The computer-implemented method of claim 9, wherein the notification on 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.

15. 10. The computer-implemented method of claim 9, further comprising triggering a second notification to the predetermined application in response to determining that the patient is likely to experience the adverse healthcare condition.

16. 16. The computer-implemented method of claim 15, wherein the second notification includes at least one of instructions that the patient should contact the physician, instructions that the patient should pick up medication at a pharmacy, or instructions that the patient should contact emergency services.

17. 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 entered by a patient receiving the bispecific antibody treatment on a predefined application executed by a patient computing device; Obtaining second health data passively collected by a wearable device worn by the patient; deploying a machine learning model on the first health data and the second health data to determine whether the patient is likely to experience an adverse health outcome following the treatment; triggering one or more notifications in response to the determining that the patient is likely to experience the adverse health condition; and Including, the system.

18. 20. The system of claim 17, wherein the operations further comprise training the machine learning model using a supervised approach by passing labeled data of a patient cohort through the model.

19. 20. The system of claim 17, 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.

20. 20. The system of claim 17, wherein the one or more notifications include at least one of a patient notification on the given application and a physician notification on a physician dashboard.

Images