Low-Power Receiver for In Vivo Channel Detection and Ingestible Sensor Detection at the Fluctuation Frequency

Abstract

To provide a system and the like which can increase the accuracy of physiological metrics while detecting if a patient ingested digital medicine and / or improve performance of a wearable device.SOLUTION: A wearable device can comprise machine executable instructions that when executed by a processor, cause the processor to perform various algorithms, such as, for example, at least one of a step count algorithm, a body angle algorithm, a heart rate algorithm, a peak finder algorithm, an adaptive thresholding algorithm, a heart rate variability algorithm, a R-R cleaning algorithm, a delta R- R cleaning algorithm, a merge twin interval algorithm, a split tali intervals algorithm, an absorb short intervals algorithm, a bimodal detection algorithm, and a resting algorithm.SELECTED DRAWING: Figure 1

Description

Background Art

[0001] Cross - reference to Related Applications This application claims priority to U.S. Provisional Patent Application No. 62 / 685,878, filed on June 15, 2018, entitled "LOW POWER RECEIVER FOR IN VIVO CHANNEL SENSING AND INGESTIBLE SENSOR DETECTION WITH WANDERING FREQUENCY", the entire contents of which are incorporated herein by reference in their entirety.

[0002] A wearable receiver assembly can be used to detect signals transmitted through an individual from an ingestible event marker (IEM) and / or other physiological metrics. Various examples of such receiver assemblies can feature reusable components including firmware and electronics, and disposable adhesive strip components including electrodes and a power source. There are challenges in data analysis from IEMs and other physiological metrics.

Summary of the Invention

Means for Solving the Problems

[0003] In one example, a system for determining a patient's step count is provided. The system includes a wearable device and at least one processor of the wearable device and a remote device communicatively coupled to the wearable device. The wearable device includes an accelerometer and is configured to be coupled to the patient's body and to detect discontinuous data using at least the accelerometer. The discontinuous data includes a frame of ingestible sensor data and a frame of the patient's physiological data scattered in time gaps between frames of ingestible sensor data. The processor is configured to determine a step count within a speed range of 80 to 150 steps per minute using the detected physiological data, measure over at least 1000 steps, and have an average error of ±3 percent.

[0004] In another example, a wearable device including a processor coupled to a non-transitory memory is provided. The non-transitory memory includes machine-executable instructions that, when executed by the processor, cause the processor to receive discontinuous data including a frame of ingestible sensor data and a frame of the patient's physiological data scattered in time gaps between frames of ingestible sensor data, determine a step count in a speed range of 80 to 150 steps per minute using the detected physiological data, measure over at least 1000 steps, and have an average error of ±3 percent.

[0005] In yet another example, a method for determining a patient's step count from discontinuous data is provided. The method includes receiving discontinuous data including a frame of ingestible sensor data and a frame of physiological data scattered in time gaps between frames of ingestible sensor data. The physiological data includes accelerometer data from an accelerometer. The method includes enhancing the accelerometer data, calculating the number of level crossings in the enhanced accelerometer data, and thereby obtaining a step count.

[0006] In one example, a system for automatically determining an orientation is provided. The system includes a wearable device and at least one processor of the wearable device and a remote device communicatively coupled to the wearable device. The wearable device includes an accelerometer. The wearable device is configured to be coupled to a patient's body and to detect discontinuous data using at least the accelerometer. The discontinuous data includes a frame of ingestible sensor data and a frame of the patient's physiological data scattered in a time gap between frames of ingestible sensor data. The processor is configured to automatically determine the orientation of the wearable device with respect to the patient's body using the detected physiological data.

[0007] In another example, a wearable device including a processor coupled to a non-transitory memory is provided. The non-transitory memory includes machine-executable instructions that, when executed by the processor, cause the processor to receive discontinuous data including a frame of ingestible sensor data and a frame of the patient's physiological data scattered in a time gap between frames of ingestible sensor data, the physiological data including accelerometer data, and to automatically determine the orientation of the wearable device with respect to the patient's body using the accelerometer data.

[0008] In yet another example, a method for automatically determining an orientation is provided. The method includes receiving discontinuous data including a frame of ingestible sensor data and a frame of physiological data scattered in a time gap between frames of ingestible sensor data, the physiological data including accelerometer data from a wearable device. The method also includes automatically determining the orientation of the wearable device with respect to the patient's body using the accelerometer data.

[0009] In one example, a system for determining a patient's heart rate is provided. The system includes a wearable device having electrodes. The wearable device is configured to be coupled to the patient's body and is configured to detect discontinuous data using at least the electrodes. The discontinuous data includes frames of ingestible sensor data and frames of the patient's physiological data scattered in time gaps between frames of ingestible sensor data. The system also includes at least one vector coprocessor of the wearable device and a remote device communicatively coupled to the wearable device. The vector coprocessor is configured to enhance the frames of physiological data. The system also includes at least one processor of the wearable device and the remote device. The processor is configured to determine the patient's heart rate using the enhanced frames of physiological data.

[0010] In another example, a wearable device including a processor coupled to a non-transitory memory is provided. The non-transitory memory includes machine-executable instructions that, when executed by the processor and / or a vector coprocessor, cause the processor and / or coprocessor to receive discontinuous data including frames of ingestible sensor data and frames of the patient's physiological data scattered in time gaps between frames of ingestible sensor data, cause the coprocessor to enhance the frames of physiological data, and cause the processor to determine the patient's heart rate using the enhanced frames of physiological data.

[0011] In yet another example, a method for determining a patient's heart rate is provided. The method includes receiving discontinuous data using at least electrodes. The discontinuous data includes frames of ingestible sensor data and frames of the patient's physiological data scattered in time gaps between frames of ingestible sensor data. The method also includes enhancing the frames of physiological data by a coprocessor and determining the patient's heart rate by a processor using the enhanced frames of physiological data.

[0012] In one example, a system for determining level crossings in discontinuous data is provided. The system includes a wearable device and at least one processor of the wearable device and a remote device communicatively coupled to the wearable device. The wearable device is configured to be coupled to a patient's body and configured to detect continuous data. The discontinuous data includes frames of ingestible sensor data and frames of the patient's physiological data scattered in time gaps between frames of ingestible sensor data. The processor is configured to handle boundary effects in the frames of physiological data and calculate the number of level crossings.

[0013] In another example, a wearable device including a processor coupled to a non-transitory memory is provided. The non-transitory memory includes machine-executable instructions that, when executed by the processor, cause the processor to receive discontinuous data including frames of ingestible sensor data and frames of the patient's physiological data scattered in time gaps between frames of ingestible sensor data, handle boundary effects in the frames of physiological data, and calculate the number of level crossings in the physiological data.

[0014] In yet another example, a method for determining the number of level crossings in discontinuous data is provided. The method includes receiving discontinuous data including a frame of ingestible sensor data and a frame of physiological data from a patient that is scattered in a time gap between frames of ingestible sensor data, handling boundary effects in the frame of physiological data, and calculating the number of level crossings in the discontinuous data.

[0015] In one example, a system for determining a patient's heart rate variability is provided. The system includes a wearable device and at least one processor of the wearable device and a remote device communicatively coupled to the wearable device. The wearable includes an electrode device configured to be coupled to a patient's body and configured to detect discontinuous data using at least the electrodes. The discontinuous data includes a frame of ingestible sensor data and a frame of physiological data from the patient that is scattered in a time gap between frames of ingestible sensor data. The processor is configured to group at least two of the frames of physiological data together into a block and use the block to determine the patient's heart rate variability.

[0016] In another example, a wearable device including a processor coupled to a non-transitory memory is provided. The non-transitory memory includes machine-executable instructions that, when executed by the processor, cause the processor to receive discontinuous data including a frame of ingestible sensor data and a frame of physiological data from the patient that is scattered in a time gap between frames of ingestible sensor data, group at least two of the frames of physiological data together into a block, and use the block to determine the patient's heart rate variability.

[0017] In yet another example, a method for determining a patient's heart rate variability is provided. The method includes receiving discontinuous data including a frame of ingestible sensor data and a frame of physiological data from the patient that is scattered in time gaps between frames of ingestible sensor data, grouping at least two of the frames of physiological data together into a block, and using the block to determine the patient's heart rate variability.

[0018] In one example, a system for determining a patient's rest is provided. The system includes a wearable device and at least one processor of the wearable device and a remote device communicatively coupled to the wearable device. The wearable device includes an accelerometer and is configured to be coupled to the patient's body and to detect discontinuous data using at least the accelerometer and electrodes. The discontinuous data includes a frame of ingestible sensor data and a frame of physiological data from the patient that is scattered in time gaps between frames of ingestible sensor data. The physiological data includes accelerometer data from the accelerometer. The processor is configured to determine that the patient is at rest based on the accelerometer data.

[0019] In another example, a wearable device including a processor coupled to a non-transitory memory is provided. The non-transitory memory includes machine-executable instructions that, when executed by the processor, cause the processor to receive discontinuous data including a frame of ingestible sensor data and a frame of physiological data from the patient that is scattered in time gaps between frames of ingestible sensor data, and to determine that the patient is at rest based on accelerometer data.

[0020] In yet another example, a method for determining a patient's rest is provided. The method includes receiving discontinuous data including a frame of ingestible sensor data and a frame of physiological data from the patient that is scattered across time gaps between frames of ingestible sensor data, and determining that the patient is at rest based on accelerometer data.

[0021] The novel features of the various aspects described herein are set forth in detail in the appended claims. However, various aspects regarding both the construction and method of operation may be better understood by reference to the following description taken in conjunction with the accompanying drawings.

Brief Description of the Drawings

[0022]

Figure 1

[0023]

Figure 2

[0024]

Figure 3

[0025]

Figure 4A

Figure 4B

Figure 4C

Figure 4D

Figure 4E

[0026]

Figure 5

[0027]

Figure 6

[0028]

Figure 7A

Figure 7B

[0029]

Figure 8

[0030]

Figure 9

[0031]

Figure 10A

Figure 10B

Figure 10C

Figure 10D

Figure 10E

[0032]

Figure 11A

Figure 11B

Figure 11C

[0033]

Figure 12

[0034]

Figure 13

[0035]

Figure 14

[0036]

Figure 15

[0037]

Figure 16

[0038]

Figure 17

[0039]

Figure 18

[0040]

Figure 19

[0041]

Figure 20A

Figure 20B

[0042]

Figure 21A

Figure 21B

Figure 21C

Figure 21D

[0043]

Figure 22

[0044]

Figure 23

[0045]

Figure 24

[0046]

Figure 25

[0047]

Figure 26

[0048]

Figure 27

[0049]

Figure 28

[0050]

Figure 29

[0051]

Figure 30

[0052]

Figure 31

[0053]

Figure 32

[0054]

Figure 33

[0055]

Figure 34

[0056]

Figure 35

[0057]

Figure 36A

Figure 36B

Figure 36C

Figure 36D

Figure 36E

[0058]

Figure 37

Figure 38

Figure 39

[0059]

Figure 40

[0060]

Figure 41

[0061]

Figure 42

[0062]

Figure 43

[0063]

Figure 44A

Figure 44B

Figure 44C

Figure 44D

Figure 44E

[0064]

Figure 45A

Figure 45B

Figure 45C

Figure 45D

[0065]

Figure 46

[0066]

Figure 47

[0067]

Figure 48

[0068]

Figure 49

[0069]

Figure 50

Mode for Carrying Out the Invention

[0070] For a general understanding of the structure, function, and use of the disclosed items and methods, various examples are described and explained herein. The various examples described and explained herein are non-limiting and non-exhaustive. Accordingly, the present invention is not limited by the description of the various non-limiting and non-exhaustive examples disclosed herein. Rather, the present invention is defined only by the claims. The features and characteristics described and / or recited in connection with the various examples may be combined with the features and characteristics of other examples. Such modifications and variations are intended to be included within the scope of this specification. Therefore, the claims may be amended to enumerate any feature or characteristic that is expressly or inherently described or supported in this specification. Further, the applicant reserves the right to amend the claims to affirmatively disclaim any feature or characteristic that may exist in the prior art. The various examples disclosed and described herein may include, consist of, or consist essentially of the features and characteristics variously described herein.

[0071] References in this specification to "various examples", "some examples", "one example", "an example", or similar phrases mean that a particular feature, structure, or characteristic described in connection with the example is included in at least one example. Thus, appearances of the phrases "in various examples", "in some examples", "in one example", "in an example", or similar phrases in the specification are not necessarily referring to the same example. Further, the particular features, structures, or characteristics described may be combined in any suitable manner in one or more examples. Accordingly, a particular feature, structure, or characteristic described or recited in connection with one example may be combined, in whole or in part, with the features, structures, or characteristics of one or more other examples without limitation. Such modifications and variations are intended to be included within the scope of this example.

[0072] Unless otherwise specified in this specification, all numerical parameters should be understood to be preceded by the word "about" in all cases, and the numerical parameters have the inherent variability characteristics of the underlying measurement techniques used to determine the numerical values of the parameters. At least, and not as an attempt to limit the application of the doctrine of equivalents to the claims, each numerical parameter described in this specification should be interpreted by applying ordinary rounding techniques in light of at least the reported significant digits.

[0073] Also, any numerical range recited in this specification includes all sub-ranges subsumed within the recited range. For example, the range "1 to 10" includes all sub-ranges between the recited minimum value of 1 and the recited maximum value of 10 (including both ends), i.e., all sub-ranges having a minimum value of 1 or more and a maximum value of 10 or less. Any maximum numerical limitation recited in this specification is intended to include all lower numerical limitations subsumed therein, and any minimum numerical limitation recited in this specification is intended to include all higher numerical limitations subsumed therein. Accordingly, the applicant reserves the right to correct this specification, including the claims, to expressly recite any sub-ranges subsumed within the expressly recited range. All such ranges are inherently described in this specification.

[0074] Unless otherwise specified, even when "at least one" or "one or more" is explicitly used in a particular instance, the grammatical articles "a", "an", and "the", as used in this specification, are intended to include "at least one" or "one or more". Accordingly, the foregoing grammatical articles are used in this specification to refer to one or more (i.e., "at least one") of the specifically identified elements. Further, unless the context of usage requires otherwise, the use of a singular noun includes the plural, and the use of a plural noun includes the singular.

[0075] A wearable device can be coupled (e.g., attached) to a patient's body (e.g., skin) and can determine whether the patient has ingested a digital medicine (e.g., an ingestible event marker (IEM) embedded in a pill or other pharmaceutical product) and / or the frequency of ingestion from ingestible sensor data generated by the IEM. The ingestible sensor data can be generated from the IEM after contact with a patient's body fluid, e.g., gastric acid. The wearable device can also determine physiological metrics such as step count, body angle, heart rate, heart rate variability, rest, and resting heart rate. The wearable device can be battery-powered and can have limited resources such as memory, battery life, computing power, and communication bandwidth, but the wearable device needs to detect all ingestions of digital medicine by the patient that include an IEM (e.g., high frequency, in-body electrical signal - 10 KHz or greater) and may need to detect and / or receive various types of physiological data (e.g., high-resolution sensor data such as electrocardiogram (ECG) data and accelerometer data). Due to the high performance requirements but limited resources, various algorithms and other technological innovations are presented herein to optimize the performance of the wearable device and / or a system comprising the wearable device and improve battery life.

[0076] Various algorithms (e.g., step count algorithm, body angle algorithm, heart rate algorithm, peak finder algorithm, adaptive thresholding algorithm, heart rate variability algorithm, R-R cleaning algorithm, delta R-R cleaning algorithm, merge twin interval algorithm, split toll interval algorithm, absorb short interval algorithm, bimodality detection algorithm, resting algorithm) and other technological innovations can be standalone in a wearable device or distributed across a wearable device and remote devices (e.g., paired mobile device, backend server, cloud). The various algorithms can be executed by a processor of the wearable device and / or a processor of the remote device. The remote device may have fewer resource constraints, but the remote device may receive low-resolution data post-processed by a patch, which can affect the accuracy of physiological metrics. Thus, the various algorithms and other technological innovations can balance the limited resources of the wearable device with the need for high-accuracy physiological metrics such as, for example, ANSI EC-13.

[0077] A wearable device and / or a system including a wearable device can be configured to detect and / or receive discontinuous data including a frame of ingestible sensor data and a frame of the patient's physiological data scattered in the time gap between the frames of ingestible sensor data. Different types of physiological data can be detected, received, and / or processed in parallel, while the ingestible sensor data can be detected, received, and / or processed serially with the physiological data. That is, the wearable device can quickly switch between detecting, receiving, and / or processing the ingestible sensor data and detecting, receiving, and / or processing the physiological data. The ingestible sensor data and the physiological data can be continuously detected, received, and / or processed and may not be temporally parallel to each other. Connecting and / or summarizing the frames of physiological data to obtain an accurate physiological metric while detecting whether the patient has ingested digital medicine can be a challenge.

[0078] Accordingly, examples of the present disclosure that can increase the accuracy of physiological metrics and / or improve the performance of the wearable device while detecting whether the patient has ingested digital medicine can include various algorithms according to the present disclosure. Examples of the present disclosure can accurately process discontinuous data, which can enable reduction of memory requirements and reduction of processing requirements.

[0079] The frames of data utilized can be prioritized based on the desired power consumption (e.g., battery life), desired accuracy, and / or desired data transfer size of the wearable device and / or the system including the wearable device. In various examples, the wearable device and / or the system including the wearable device can be configured to detect and / or receive a first continuous data including a frame of ingestible sensor data and a second continuous data including a frame of physiological data.

[0080] Wearable Device Structure

[0081] FIG. 1 shows a system diagram of an example of a wearable device 102. The wearable device can be configured to be removably attached to a patient's skin. The wearable device can be re-wearable or the wearable device can be disposable. Wearable device 102 can include at least two components including a disposable component 110 and an electronics module 120 (e.g., a reusable electronics module). Each of the disposable component 110 and the electronics module can include a printed circuit board assembly (PCBA). Electronics module 120 can include a computing platform 108, a processor 111 (e.g., a microcontroller unit (MCU)), a wireless communication circuit 106, a universal serial bus 134 (USB), an accelerometer (ACC) 122, a memory 112, an LED 136, a 32KHz crystal clock (X-Tal) 126, a user button 140 that can be used to initiate a communication connection with an external device, and a sensor interface 116. In various examples, electronics module 120 can include a gyroscope, a body composition circuit, an SpO2 oximetry circuit, and circuits for processing an ECG signal, a temperature signal, and an accelerometer signal. The SpO2 pulse oximetry circuit can monitor the functional oxygen saturation of arterial blood by calculating the ratio of oxyhemoglobin to hemoglobin that can transport oxygen. The SpO2 pulse oximetry circuit can be configured to provide continuous non-invasive measurements of SpO2 and can display a plethysmograph waveform. The heart rate value can be derived from the SpO2 pulse oximetry signal. Electronics module 220 also includes a connection port to an external memory, a connection port to an external sensor, and a hardware accelerator.

[0082] The electronics module 120 may include an application - specific integrated circuit (ASIC) - based computing platform 108 that can include a hardware structure and a software framework for implementing various functions of the wearable device 102. The computing platform 108 can be placed on the PCBA of the electronics module 120 and interfaced with it. The disposable component 110 can be interfaced with the PCBA of the electronics module 120. The electronics module 120 and the disposable component 110 can each be placed on the PCBA of their respective components, 110, 120, or may include additional modules that can be removed from the PCBA of their respective modules, 110, 120.

[0083] The computing platform 108 may include circuits designed to interface with various sensors and combinations of components of the wearable device 102. For example, the computing platform 108 can provide a combination of an analog front - end, vector / digital signal processing, a microprocessor, and memory in a single low - power ASIC / chip that can include multiple functions such as, for example, detection of ingestible event markers, detection and decoding of electrocardiogram (ECG) signals, AC skin impedance measurement, temperature measurement (e.g., of the skin and / or surroundings), DC skin impedance (e.g., galvanic skin response (GSR)) measurement, accelerometer measurement, and software radio for other biological / medical data sensors.

[0084] Processor 111 can be a central processing unit (CPU). Processor 111 can be implemented as a general-purpose processor, a chip multiprocessor (CMP), a dedicated processor, an embedded processor, a digital signal processor (DSP), a network processor, a media processor, an input / output (I / O) processor, a media access control (MAC) processor, a wireless baseband processor, a vector coprocessor, a microprocessor, for example, a complex instruction set computer (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, and / or a very long instruction word (VLIW) microprocessor, or other processing devices. The processor can also be implemented by a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a programmable logic device (PLD), etc.

[0085] Processor 111 can be configured to execute an operating system (OS) and various mobile applications. For example, the OS can include an operating system generally known by the trade name of Microsoft Windows OS, and any other dedicated or open source OS. Mobile applications can include, for example, a phone application, a camera (e.g., digital camera, video camera) application, a browser application, a multimedia player application, a game application, a messaging application (e.g., email, short message, multimedia), a viewer application, etc. Processor 111 can be arranged to receive information through a communication interface. The communication interface can include any suitable hardware, software, or combination of hardware and software that can connect the wearable device 102 to one or more networks and / or devices.

[0086] Processor 111 may include, among other components, an ARM Cortex™ M3 processor for real-time applications, a signal processing accelerator (e.g., a vector coprocessor), such as a Vector Math Accelerator, program memory, data memory, serial interfaces, such as SPI, a universal asynchronous receiver / transmitter (UART), a two-wire multi-master serial single-ended bus interface (I2C), general-purpose input / output (GPIO), a real-time clock, an analog-to-digital converter (ADC), a gain and conditioning circuit for biopotential signals, a light-emitting diode (LED) driver, etc. Processor 111 can receive signals from each of the sensors by operating the analog front end of the analog sensors or receiving digital data from the sensors using the ADC converter. Processor 111 can process the data and can also store the results in memory 112 in the form of data records. In various examples, Processor 111 may have a very long instruction word (VLIW) processor architecture.

[0087] The wireless communication circuit 106 can be a mobile chipset radio frequency (RF) wireless circuit or simply a cellular radio. The wireless communication circuit 106 may be a low-power mobile chipset and can be configured to connect to a cellular network as well as other remote devices (e.g., wireless devices such as mobile phones, smartphones, tablet computers, notebook computers, gateway devices, etc.). The wireless communication circuit 106 can include an antenna for receiving and transmitting wireless signals, a transmitter circuit, a receiver circuit, and a link master controller including a mechanism for connecting (establishing a link) to another external wireless device and transferring data, as described in detail below. The link master controller can establish a connection to an external device, e.g., a mobile device. As the master of the link, the link master controller can perform control of data transmission on the link to the external device, including timing control and radio frequency control (channel hopping). The link master controller can send a signal to the remote device with an instruction giving the number of data records stored in the memory (the total number of all data records and the total number of records of each data type). The wireless communication circuit 106 can be implemented using mobile chipsets available from various vendors, including but not limited to Tegra by Nvidia, Snapdragon by Qualcomm, OMAP by Texas Instruments, Exynos by Samsung, Ax by Apple, NovaThor by ST-Ericsson, Atom by Intel, i.MX by Freescale Semiconductor, RK3xxx by Rockchip, A31 by AllWinner. Such mobile chipsets are known in the art, among other aliases, as "mobile", "wireless", "cellular phone", "cell phone", "handphone (HP)", "smartphone" and are used in mobile phones. In various examples, the wearable device 102 can communicate via a wired circuit.In various examples, the wearable device 102 can communicate via Bluetooth.

[0088] After each connection, the processor 111 can continue to receive all sensor signals, process the data, and store new data records in the memory 112. For each subsequent connection, the link master controller can send a signal to a remote device (e.g., external to the wearable device 102) along with the new data records since the last connection, and can confirm that the data records were successfully transmitted. The link master controller can receive a signal from the remote device attesting whether the remote device is ready to receive the data records, and can also receive a signal from the remote device attesting which data records were not successfully transferred. The link master controller can avoid repeating the transmission of data records that have already been sent, thereby improving the battery power consumption for long-term operation, and can retransmit data records that were not successfully transferred. The link master controller can delete all or part of the data records that were successfully transferred from the memory 112 at a later time (e.g., when the memory 112 is full).

[0089] The memory 112 can be non-transitory memory and can contain machine-executable instructions that, when executed by the processor 111, can cause the processor 111 and / or a processor on the remote device to implement various algorithms and other innovative functions described herein. In various examples, at least some of the machine-executable instructions are stored in the memory on the remote device.

[0090] The sensor interface 116 can be disposed between the electrode 150 and a bandpass filter or a channel. The sensor interface 116 can provide an analog front end and may include a programmable gain or fixed gain amplifier, a programmable low-pass filter, and a programmable high-pass filter. The sensor interface 116 may include, for example, an active signal conditioning circuit such as a strain gauge measurement circuit. One channel can receive low-frequency information related to the physiological data of a patient (e.g., user, subject), and another channel can receive high-frequency information related to an electronic device within the patient. The high-frequency channel can receive DC data of the patient. The high-frequency channel data can be communicated to a digital signal processor (DSP) implemented in the computing platform 108 and then to the processor 111 for expansion and decoding, or can be communicated directly to the processor 111. The low-frequency channel data can be communicated to the DSP portion of the computing platform 108 and then to the processor 111, or can be communicated directly to the processor 111. The DSP portion and the processor 111 can decode the data from the high-frequency channel and the low-frequency channel. The data can then be processed and prepared for transmission.

[0091] Signal processing may or may not be applied to the raw data collected from the channels. Signal processing can be performed in real space, complex number space, or polar coordinate space. Signal processing functions include, among others, filters such as finite impulse response (FIR) and infinite impulse response (IIR), mixers, fast Fourier transform (FFT), and trigonometric functions. The raw data may simply be stored in memory 112 and processed downstream later. Signal processing may be performed by processor 111 or by a signal processing accelerator that can be incorporated into computing platform 108. Physiological data from various sensors on wearable device 102 can be processed by processor 111 and transmitted in real time or as raw data, or induced quantities or parameters may be transmitted. Physiological data may include accelerometer data, ECG data, and other physiological data. The accelerometer data may be temporally parallel to the ECG data.

[0092] Electronics module 120 may include two temperature sensors 124 that are the same but are located at different positions, for example, one near the skin and the other extending into the ambient environment to measure additional data. Temperature sensor 124 can be configured to measure and record skin, ambient, and circuit board temperatures. The temperature sensors 124 can be used to measure the heat flux between the skin and the ambient temperature sensors. Temperature sensor 124 can be a thermistor device with a negative temperature coefficient (NTC) or a positive temperature coefficient (PTC). An integrated semiconductor device can be used for temperature sensor 124. A temperature signal can be provided to processor 111, processed by processor 111, and prepared for transmission by the transmitter portion of wireless communication circuit 106.

[0093] The accelerometer 122 can be a three-axis accelerometer having a resampling frequency correction processor. As shown in FIG. 2, an example of a wearable device is presented, with the associated X, Y, and Z axes shown based on when the embedded accelerometer of the wearable device can measure and output accelerometer data. The accelerometer 122 can include different recording modes. For example, the wearable device 102 can record only the raw accelerometer X, Y, Z data, or the wearable device 102 can record the raw accelerometer X, Y, Z data and normal accelerometer metrics.

[0094] Returning to FIG. 1, the accelerometer 122 can be a digital accelerometer including a MEMS-based acceleration sensor element, a digitizer, and digital interface control logic. The accelerometer 122 can use a low-precision resistor-capacitor (RC) oscillator to strobe the digitizer sampling input. The electronics module 120 can include an accelerometer sampling frequency correction processor that receives signals from the accelerometer 122 and performs resampling to cancel out RC oscillator errors.

[0095] The accelerometer 122 may include a sampling frequency correction processor including a reference clock (high-precision oscillator), a fixed up-sampling block, a digital filter, a programmable down-sampling block, and a control circuit that selects a down-sampling coefficient based on the comparison of the timing of the signal from the accelerometer and the reference clock. The resampling function can hold the alignment with respect to the reference clock in the sliding window to obtain an accurate sampling speed. The time algorithm can calibrate the real-time 32 kHz crystal clock (X-Tal) 126. The accelerometer 122 sampling frequency correction processor can set the down-sampling coefficient for each frame of data from the accelerometer signal. The timing of the accelerometer signal can be continuously tracked, and the down-sampling coefficient can be selected to minimize the cumulative timing error. Therefore, the accelerometer data from the accelerometer 122 can be aligned with a high-precision and accurate clock.

[0096] The electronics module 120 can adopt a low-power and low-memory data storage and transfer scheme. For example, the storage and transfer of data in the memory 112 can be optimized for low power and low memory usage. The physiological data from the sensor signal can be stored in the memory 112 as data records each having a type identifier. The data records can be transferred as packet payloads to a remote device by the wireless communication circuit 106. The data records can be stored sequentially with variable lengths to optimize the space usage in the memory 112. A data directory can be provided in the memory 112, thereby enabling fast record read access from the memory 112. The data directory can also enable a quick count of the type-specific data records.

[0097] The electronics module 120 can adopt a high-reliability integrity data storage and transfer scheme. For example, the wearable device 102 memory storage and transfer scheme can be designed for high-reliability data integrity. For each data record stored in the memory 112 of the wearable device 102, there may be an error detection code that can be used to detect damage to the data record. When the wearable device 102 reads a data record from the memory 112 prior to transferring a data packet to a remote device, the error detection code can be checked. When the wearable device 102 detects damage to a stored data record, an error signal can be transmitted to the remote device by the wireless communication circuit 106. Each packet transferred from the wearable device 102 to the remote device may include an error detection code, which can be used to detect packet damage at the remote device.

[0098] The signal processing accelerator portion of computing platform 108 may include a computing engine optimized to implement high-efficiency signal processing tasks. The signal processing function can be hard-coded with logic that can be more than 10 times more efficient compared to software-based algorithms implemented in software executed on processor 111 or other microcontroller units. The efficiency can be a reduction in chip size, a reduction in power consumption, and / or a reduction in clock speed. The signal processing function can maintain a certain level of programmability while utilizing execution units that are optimized computations. For example, the signal processing function can enable FFT calculations for data sets of various sizes, but can employ a high-speed Fourier transform (FFT)-butterfly engine that can maintain a significantly improved efficiency compared to software executed on processor 111. The execution unit may also be a multiply-accumulate unit (MAC), which can be a common DSP functional block or can be a floating-point calculation unit(s) or FIR filter primitive, etc. In these examples, the efficiency of a given integrated circuit process may be greater than the efficiency of software on processor 111 but less than the efficiency of dedicated hardware, but can be much more flexible in terms of balancing limited resources and the accuracy of physiological measurements.

[0099] The signal processing accelerator can maintain an interface with the processor 111. This interface may include a first-in first-out (FIFO) register, dual-port memory, the direct memory access (DMA) engine of the processor 111, and / or registers. The interface may include forms of contention recognition or avoidance that may be handled at the register level or the memory block level. The mechanisms involved may include a set of register flags that can be polled by the processor 111 and the signal processing accelerator, and interrupts to signals can block or delay the function of holding read or write requests until a higher-priority device has completed its activity.

[0100] The disposable component 110 can be connected to the PCBA of the electronics module 120. The disposable component may include sensors attached to what is being monitored (human, animal, machine, building, etc.) with respect to the interface, such as skin potential (EDA) sensors, GSR sensors, temperature sensors (e.g., of the skin and / or surroundings), body composition sensors (50 Hz), SpO2 / pulse oximetry sensors, strain gauge sensors, accelerometers, and other biological / medical data sensors. Various algorithms executed by the computing platform 108 or the processor 111 can generate metrics such as step count, body angle, heart rate, heart rate variability, rest, resting heart rate, heat flux, respiratory rate, stress level, fall detection, and other physiological metrics.

[0101] The disposable component 110 may also include a battery 160, a cradle for holding the battery, a battery holder or housing (cover), an adhesive, and electrodes 150 (e.g., at least two electrodes). Power can be provided from the battery 160 to the wearable device 102. The battery 160 can be a disposable coin cell having a battery life approximately equal to the useful life of the adhesive of the disposable component 110. The adhesive can attach the wearable device 102 to the patient's skin. The adhesive can have a useful life of 3 to 10 days for most patients. The electrodes 150 can include a hydrogel electrode and an individual stainless-steel electrode. The hydrogel electrode can be used to detect high-frequency in-body electrical signals (above 10 KHz) that can indicate that a patient has ingested digital medicine.

[0102] The memory 112 can include any machine-readable or computer-readable medium capable of storing data, including both volatile and non-volatile memory. For example, the memory 112 can include read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), double data rate DRAM (DDR-RAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory (e.g., NOR or NAND flash memory), content-addressable memory (CAM), polymer memory (e.g., ferroelectric polymer memory), phase-change memory (e.g., ovonic memory), ferroelectric memory, silicon oxide nitride oxide silicon (SONOS) memory, disk memory (e.g., floppy disk, hard drive, optical disk, magnetic disk), or card (e.g., magnetic card, optical card), or any other type of medium suitable for storing information.

[0103] Step count

[0104] The wearable device 102 can be worn by a patient by attaching the wearable device to the patient using an adhesive of a disposable component 110 (e.g., an adhesive strip). When the patient moves, the accelerometer 112 can provide an accelerometer signal based on the acceleration force experienced by the accelerometer 122. Variations in acceleration can indicate the patient's motion / activity. The accelerometer signal can be converted into accelerometer data by the wearable device 102.

[0105] Walking can be a periodic / regular motion that can be interpreted as a strong peak in the accelerometer data and / or autocorrelation data obtained from the accelerometer signal. The accelerometer data can be analyzed and used to calculate the number of steps (e.g., step count) the patient has walked. For example, as shown in FIG. 3, accelerometer data 302 that may include individual traces for each of the axes X, Y, and Z is provided. The accelerometer data 302 includes acceleration data for a 14 - second block of acceleration data for which a patient wearing the wearable device 102 has walked 24 steps. Using a count of the number of times the accelerometer data 302 exceeds a threshold, a physiological metric of the step count from the accelerometer data 302 can be determined. The step count measured from the accelerometer data 302 is 103 steps per minute based on measuring 24 steps over a 14 - second period.

[0106] The wearable device 102 can be used by patients who have difficulty moving (e.g., elderly patients) or who walk at a slow pace. As used herein, "slow walking" refers to a step rate within the range of 15 to 80 steps per minute, and normal walking refers to a step rate within the range of 80 to 150 steps per minute. Previous comparison algorithms may not be able to accurately calculate the step count from the accelerometer data of patients who have slow feet (e.g., drag their feet and / or move slowly) or may be driving. For example, the accelerometer data may not appear as normal walking steps, and the accelerometer data may not be easily analyzable to calculate the step count. For example, the upper part of FIG. 4A shows an example of accelerometer data at a moving speed of 100 steps per minute (e.g., normal walking), and the upper part of FIG. 4C shows an example of accelerometer data at a moving speed of 50 steps per minute (e.g., slow walking).

[0107] The comparison algorithm may only rely on counting the level crossings in the autocorrelation data (e.g., the threshold indicated by the dashed line in FIGS. 4A to 4E). As shown in the lower part of FIG. 4A, as a result of counting the threshold crossings of the autocorrelation data generated by normal walking, an accurate step count (e.g., exceeding + / - 10%) may be obtained based only on the level crossings. However, as shown in the lower part of FIG. 4C, as a result of counting the level crossings of the autocorrelation data obtained by slow walking, an inaccurate step count may be obtained based only on the level crossings.

[0108] Referring to FIG. 4E, a plot of step count data points is provided, where each point represents a 7 - second block of accelerometer data consisting only of each activity identified in FIG. 4E analyzed by the comparison algorithm. Data for normal walking at 100 steps per minute was sampled over 4 minutes, with an expected value of 400 steps for the step count; data for slow walking at 50 steps per minute was sampled over 4 minutes, with an expected value of 200 for the step count; data for slow shuffling at 60 steps per minute was sampled over 4 minutes, with an expected value of 240 for the step count; data for medium - speed shuffling at 80 steps per minute was sampled over 4 minutes, with an expected value of 320 for the step count; drive data (e.g., 0 steps per minute) was sampled over various times, with an expected value of 0 for the step count.

[0109] In addition to the inaccurate step counts for slow walking, as shown in FIGS. 4B, 4E, and 5, driving can cause incorrect step counts. Further, as shown in Table 1, a comparative pedometer including the comparison algorithm can provide inaccurate step counts (e.g., detect incorrect step counts during driving). Further, the comparative pedometer receives accelerometer data continuously (e.g., not discontinuously).

[0110]

Table 1

[0111] Therefore, a step count algorithm is provided that inaccurately counts steps in discontinuous data including accelerometer data generated by the wearable device 102 during slow walking. The step count algorithm can determine the step count in a step rate range of 80 to 150 steps per minute using physiological data measured over at least 1000 steps and detected with an average error of ±3 percent. Further, the step count algorithm can limit, if not prevent, incorrect step counts during driving or other types of operations.

[0112] The step count algorithm can save memory and power by estimating a continuous step rate from discontinuous data. For example, every minute, the wearable device can collect a 14-second frame of accelerometer data, calculate the step rate on this frame, and interpolate the step rate to derive the number of steps in a minute. To optimize accuracy, the algorithm can consider half steps at the boundaries of the 14-second frames.

[0113] In addition, the wearable device 102 can be configured to classify data based on activity level. For example, the wearable device 102 can distinguish "intentional walking" that includes faster and more distinct steps (e.g., a first activity level) compared to incidental walking such as a simple walk from the bathroom to the kitchen (e.g., a second activity level lower than the first activity level). The type of walking can be distinguished by a step count algorithm based on accelerometer data.

[0114] The step count algorithm can receive accelerometer data and can be distributed across the wearable device 102 and the remote device for execution by the control circuit. For example, the step count algorithm can be stored in the memory 112 and utilized by the processor 111 to convert accelerometer data received from the accelerometer 122 into a physiological metric, such as a step count.

[0115] For the purpose of describing the algorithm configuration in this specification, accelerometer values are interpreted in units of "g", where "g" is the acceleration due to the Earth's gravity (approximately 9.8 m / s 2 ) unless otherwise specified by Tokuno. For performance optimization, the design implementation can operate on raw accelerometer counts.

[0116] The step count algorithm can be set to default values in the source code, but can include fixed parameters as described in Table 2 that can be adjusted without a complete or partial redesign of the step count algorithm (with a full software recompilation).

[0117]

Table 2

[0118] The step count algorithm can include programmable parameters as described in Table 3. The step count algorithm can be set to default values and can be reconfigured during manufacturing and / or during use via a wireless / priority interface. Each programmable parameter can maintain its set value through all state transitions and a complete removal of power from the wearable device 102 (e.g., battery disconnect).

[0119]

Table 3

[0120] The step count algorithm can process accelerometer data in a selected time window sampled at a selected frequency. In an example of a 14-second time window and a selected frequency of 12.5 GHz, 175 samples are in the window. The step count can be derived in a sample buffer containing a single block as shown in FIG. 6, or the sample buffer can be divided into two blocks, period 1 (P1) and period 2 (P2), as shown in FIGS. 7A-7B. In an example where the number of samples is odd, one point may be excluded so that each period is equal. In an example where the number of samples is 175, the 175th sample can be excluded so that each period is equal.

[0121] The step count algorithm can perform the evaluations, calculations, and conversions described herein and can generate an accelerometer record (ACR) as described in Table 4. The ACR can be made once or more than once per measurement period as desired.

[0122] [Table 4]

[0123] The accelerometer data can be normalized to "g" (or g 2 if it is a measure of the square of acceleration) using a fixed conversion value G defined by the sensitivity used as shown in Equation 1. The default can be a 2G sensitivity.

[0124] [Equation]

[0125] FIG. 6 shows an example of a flowchart of a step count algorithm that can accurately determine the step count during a patient's slow walking. As shown, the x-axis accelerometer data, y-axis accelerometer data, and z-axis accelerometer data, collectively referred to as accelerometer data, can be processed by the step count algorithm.

[0126] The raw acceleration data (e.g., vector) on each axis of the accelerometer data can be processed by a step count algorithm using a boxcar filter to reduce noise according to Equation 2, 602, and remove the high-frequency components of the signal.

[0127]

Equation

[0128] In the example of the default parameter values AccFs = 12.5 Hz and M = 2, frequency components lower than 3.125 Hz can be accurately reproduced.

[0129] The accelerometer data sampled at 12.5 Hz can have a tap filter, such as a 2-tap filter, etc., applied to the raw acceleration data. The more taps in the filter, the more the accelerometer data is averaged. The tap filter can determine the high frequencies that can be faithfully represented. Tap filters of various lengths can be applied to the raw acceleration data to characterize the sensitivity of the step count during activities (e.g., gym exercises). The sampling rate and digital filter (e.g., tap filter) applied to the raw acceleration data can be configured for the desired application. In various examples, the hardware of the wearable device 102 can support different sampling rates (e.g., higher sampling rates).

[0130] The post-boxcar filtering of the acceleration data on each axis of the accelerometer data calculates the squared L2 norm from each axis of the accelerometer data as shown in Equation 3, 604 for the total acceleration (totAcc, Acctotal,i ) can be converted to.

[0131]

Number

[0132] The step count algorithm can utilize the squared L2 norm instead of the L2 norm for simplification of calculations. The scaling factor (e.g., division by 2) in Equation 3 can prevent overflow / saturation of the buffer in memory. When determining and / or programming thresholds in relation to total acceleration (e.g., totActThresh, totActThreshLo), the scaling factor can be considered.

[0133] The total activity (totActivity) of the total acceleration data can be calculated by taking the standard deviation (std(totAcc)) of the total acceleration data as shown in Equation 4, 4606.

[0134]

Number

[0135] The total activity can be calculated independently for blocks P1 and P2 in an example having two blocks of accelerometer data, and as a result, two floating-point values are obtained as shown in FIGS. 7A - 7B.

[0136] Returning to FIG. 6, the total activity can be used by the step count algorithm to evaluate whether the block of accelerometer data includes valid step activity 608. For example, the step count algorithm can evaluate whether the total activity data meets or exceeds an activity threshold. If the total activity meets or exceeds the activity threshold, the step count algorithm proceeds to step 624, adjusts the accelerometer data on average, and evaluates the acceleration data for the step count.

[0137] However, if the total activity does not meet or exceed the activity threshold, the step count algorithm can evaluate whether the accelerometer data should be enhanced 610. For example, the step count algorithm can evaluate whether the total activity meets or exceeds a lower activity threshold. If the total activity does not meet or exceed the lower activity threshold, it can be determined that the accelerometer data does not contain valid step activity, and steps are not counted in the block of accelerometer data.

[0138] However, if the total activity meets or exceeds the lower activity threshold (e.g., the measured value of low amplitude activity), the block of accelerometer data can be enhanced 612 - 622. For example, all the accelerometer data can be enhanced. The lower activity threshold can enable further discrimination between true steps (e.g., slow walking) and false steps (e.g., driving) in the accelerometer data.

[0139] Accelerometer data enhancement can be performed based on the total activity and, in various examples, the energy consumption. In various examples including two blocks of accelerometer data as shown in FIGS. 7A - 7B, the enhancement can be performed independently for blocks P1 and P2. Accelerometer data enhancement can enhance the periodicity of the accelerometer data, where additional artifacts may be introduced by true steps that can be distinguished from false steps based on this enhancement.

[0140] Returning to FIG. 6, the lower total activity threshold can be adjusted based on the evaluated block of accelerometer data 612. Then, the acceleration data can be adjusted for further calculations as shown in Equation 6, thereby obtaining the mean - adjusted acceleration data (inpZM0) 614.

[0141]

Equation

[0142] Average adjustment can be performed independently for each block of accelerometer data (e.g., P1 and P2 shown in FIGS. 7A-7B). The absolute value of the average-adjusted accelerometer data can be calculated 616.

[0143] The absolute accelerometer data can be processed by a low-pass filter (LPF). That is, the absolute value can be determined by a 5-point moving average filter as a means of envelope detection as shown in Equation 7 618.

[0144]

Equation

[0145] The low-pass filtered accelerometer data can then be processed by a high-pass filter (HPF) 620. For example, as shown in Equation 8, a 4th order non-recursive high-pass filter can be utilized with respect to the accelerometer data to remove drift.

[0146]

Equation

[0147] The high-pass filtered accelerometer data can be scaled 4622 and used as an input for the calculation of autocorrelation.

[0148] FIG. 8 shows an example of enhancing accelerometer data to determine whether a user has walked or whether the accelerometer data indicates some other activity. That is, raw accelerometer data 802 from an accelerometer can be converted to processed accelerometer data 804 by processing the raw accelerometer data 802 through an absolute value filter and a low-pass filter (e.g., envelope detection). The processed accelerometer data 804 can be further converted to enhanced accelerometer data 806 by processing the accelerometer data 804, such as through a high-pass filter (e.g., drift removal), mean normalization, and smoothing. The steps shown in FIG. 8 can be performed in any order. Thereafter, a step count algorithm can extract features from the enhanced signal.

[0149] Returning to FIG. 6, as illustrated, signal enhancement data from accelerometer data averaged at 624 (inpZM) or 622 (inpZM) can be converted to autocorrelation data (e.g., AC, aCorr) at 626. The autocorrelation data at lag t is described by Equation 9. The number of lags t of the autocorrelation calculated can be governed by the parameter ACC_AC_LIM as described in Table 2.

[0150]

Equation

[0151] In various examples including two blocks of acceleration data, the autocorrelation can be calculated independently for each block (e.g., blocks P1 and P2 in FIGS. 7A-7B). Mean adjustment of the input and normalization of the output allows the term autocorrelation to be used to describe this quantity, although it may imply that AC(t) represents the autocovariance at lag t.

[0152] The step count algorithm can calculate the number of level crossings (numLC) in the autocorrelation data 628. A level crossing occurs when the signal in the data exceeds the level crossing threshold. The upward and downward level crossings of the autocorrelation data can be counted independently. The level crossings in the autocorrelation data can be determined according to the state machine shown in FIG. 9. Using the level crossings, it can be determined whether a block of acceleration data contains valid step activity 630. For example, the step count algorithm can evaluate whether the number of level crossings meets or exceeds a level crossing threshold (numLCThresh). If the number of level crossings in the acceleration data does not meet or exceed the level crossing threshold, it can be determined that the accelerometer data does not have valid step activity and the step is not counted.

[0153] When the number of level crossings meets or exceeds a level crossing threshold value, the number of level crossings (numZC) is counted as 632 with accelerometer data adjusted by 4624 (inpZM) or signal enhancement data from 4622 (inpZM). In various examples, at step 632, the level crossing can be a zero crossing (e.g., the threshold value is 0) or the number of level crossings can be different from zero crossings (e.g., the threshold value is a non - zero number). A zero crossing is when the sign of the signal in the data changes (e.g., plus becomes minus, or vice versa). In acceleration data considered to include valid step activity, the step - count algorithm can calculate the number of steps based on the total number of level crossings in the adjusted - average accelerometer data (inpZM). The level crossings in the accelerometer data (inpZM) can be determined according to the state machine shown in FIG. 9. Upward and downward level crossings can be counted independently as shown by the state machine of FIG. 9, and thus, the total step count can be divided by 2 to determine the actual step count. For example, each step of a patient includes physically lifting his / her foot (generating a downward crossing), followed by lowering his / her foot to the ground (generating an upward crossing). Thus, an upward / downward crossing pair constitutes 1 step.

[0154] The step - count algorithm can create output data including output values derived from accelerometer data (e.g., physiological metrics) and the raw acceleration data itself as an accelerometer record (ACR). The ACR can be configured as shown in Table 4 herein. The ACR can be stored in the memory of the wearable device 102 (e.g., on - board flash memory) and / or the remote device memory 112.

[0155] Referring to FIGS. 7A-7B, the average of the acceleration data in each of the axes (X, Y, Z) can be calculated by a step count algorithm, and the average acceleration data can be reported as an output value in floating point according to Equation 10. The average acceleration data can be used as an input to a body angle algorithm and can also be used to calculate a standard deviation metric. These metrics can be calculated only once for each measurement period of the accelerometer data.

[0156]

Number

[0157] The standard deviation of the acceleration data in each of the axes (X, Y, Z) can be calculated by a step count algorithm and can be reported as an output metric in floating point as shown in Equation 11. The standard deviation of the acceleration data can be calculated once for each measurement period of both the P1 and P2 blocks of the accelerometer data.

[0158]

Number

[0159] The energy consumption (EE) can be calculated by a step count algorithm as the sum of the absolute values of all negative values in the total acceleration vector according to Equation 12. EE can be calculated independently for blocks P1 and P2, resulting in two floating point values. EE can be used to determine whether a block contains valid step activity and can also be used to determine whether signal enhancement of the accelerometer data should be performed.

[0160]

Number

[0161] As shown in FIGS. 7A to 7B, by combining the total acceleration, total activity, energy consumption, and autocorrelation information from blocks P1 and P2, a single step count number (UINT16 value) can be obtained for each measurement period. The step count algorithm may include the following steps: (i) determining whether the block is qualified as a medium to high amplitude or low amplitude activity block, (ii) performing signal enhancement on the low amplitude activity block, (iii) determining whether the block includes valid step activity, and (iv) counting the number of steps in the valid block. Simply summing the step counts from blocks P1 and P2 determines the number of steps within a given measurement period. By calculating independently for blocks P1 and P2, finer accuracy becomes possible when tracking the user's step count.

[0162] A block (P1 or P2) is considered to have valid step activity when the following conditions are met: (i) the total activity in the block exceeds the threshold "accelerometer total activity low threshold", and (ii) the number of level crossings of the autocorrelation exceeds the threshold "accelerometer Num Crossing".

[0163] For blocks that meet the above conditions, the number of steps is calculated as the total number of level crossings of the total acceleration data. The step counts from blocks P1 and P2 are summed to obtain the total number of steps in the measurement period. This number is then appropriately scaled to determine the adjusted step count (i.e., AStepCount), which is an approximate measure of the number of steps per minute. The adjusted step count can be used as an input to an algorithm implemented on a wearable device and / or a remote device.

[0164] The wearable device 102 may include a scheduler (e.g., a software module external to the step count algorithm) that starts and stops the acquisition of accelerometer data according to an accelerometer interval and / or accelerometer period parameter that can be programmable parameters. The accelerometer can acquire data at a fixed sampling rate (e.g., 12.5 Hz) for the length of the accelerometer period parameter set.

[0165] In various examples, the step count algorithm may include further evaluations, such as minimum and / or maximum values, time intervals between detected steps, and amplitude variations between detected step evaluations. The step count algorithm can use at least one of the following optional features, can process each axis separately instead of combining all accelerations, can use a reference vector to determine the orientation of the patch before determining which axis(es) to use, can also adjust the threshold based on more physiological data, and can combine data from two axes. The step count algorithm can be measured over at least 1000 steps and can be accurate to ±3% for normal walking (80 - 150 steps per minute) and ±10% for slow walking (15 - 80 steps per minute). In various examples, the step count algorithm can be measured over at least 1000 steps and can be accurate to ±5% for slow walking (15 - 80 steps per minute).

[0166] Referring to FIGS. 10A - 10E, the step count algorithm can provide a more accurate step count than a comparison algorithm. The dashed lines in FIGS. 10A - 10E represent activity thresholds. As shown in the slow walking example of FIG. 10C, the step count algorithm enhances the data so that level crossings in the autocorrelation data caused by slow walking can result in a more accurate step count.

[0167] FIG. 10E shows step count values determined by a comparison algorithm and a step count algorithm from accelerometer data for normal walking, slow walking, low-speed shuffling, and driving. Data for normal walking at 100 steps per minute was sampled over 4 minutes, with an expected value of 400 steps for the step count; data for slow walking at 50 steps per minute was sampled over 4 minutes, with an expected value of 200 for the step count; data for low-speed shuffling at 60 steps per minute was sampled over 4 minutes, with an expected value of 240 for the step count; data for medium-speed shuffling at 80 steps per minute was sampled over 4 minutes, with an expected value of 320 for the step count; drive data (e.g., 0 steps per minute) was sampled over various times, with an expected value of 0 for the step count.

[0168] FIG. 10E is a plot of step data points, where each point represents one 7-second block of accelerometer data consisting only of the activities identified in FIG. 10E analyzed by the step count algorithm. FIG. 10E shows an activity threshold 4402 and a lower activity threshold 4404. As shown, the lower activity threshold 4404 enables the detection of slow walking.

[0169] Furthermore, the threshold of the step count algorithm can be adjusted as shown in FIGS. 11A - 11C. The upper right of each plot in FIGS. 11A - 11C shows that by adjusting the threshold, false step counts during driving can be limited even if not prevented by the step count algorithm.

[0170] As shown in FIG. 12A, acceleration data in the form of a periodic signal is generated from walking, and the data is autocorrelated to generate the autocorrelation data shown in FIG. 12B. Further, FIGS. 13A - 13B show autocorrelation data for other activities such as walking, driving, and sitting generated using the step count algorithm.

[0171] The step count algorithm was tested and the results were reported as shown in the following table. That is, Tables 5 to 8 show the step counts from the wearable devices installed on the patient, and the accelerometer data is processed using the comparison algorithm and the step count algorithm during different activities. Further, the results of the comparison pedometer 1 are shown. Table 5 shows the results of the wearable device installed on the left side of the patient, Table 6 shows the results of the wearable device installed on the inside of the patient, Table 7 shows the results of the wearable device installed on the right side of the patient, and Table 8 shows the results of the wearable device installed on the outside of the patient.

[0172]

Table 5

[0173]

Table 6

[0174]

Table 7

[0175]

Table 8

[0176] The comparison between Tables 5 and 7 shows that the step counts output from the wearable devices on the left side and the right side of the patient were equivalent, indicating that the installation of the patch may not affect the step count and that the step count algorithm can count steps with good reproducibility. The comparison between Tables 6 and 8 shows that the step counts reported from the wearable devices on the inside and the outside of the patient were equivalent, indicating that the installation of the patch may not affect the step count and that the step count algorithm can count steps with good reproducibility.

[0177] Tables 9 to 14 show step count values output from a comparison algorithm, a comparison pedometer 1, and a step count algorithm for various patients.

[0178] [Table 9]

[0179] [Table 10] *Includes a round trip on foot to the gym and a 2-minute sprint of various exercises at the gym with breaks in between.

[0180] [Table 11]

[0181] [Table 12] *Includes a round trip on foot to the gym and a 2-minute sprint of various exercises at the gym with breaks in between.

[0182] [Table 13]

[0183] [Table 14] *Includes a round trip on foot to the gym and a 2-minute sprint of various exercises at the gym with breaks in between.

[0184] Tables 5 to 14 show that the step count algorithm according to the present disclosure can have improved accuracy with respect to step count while minimizing incorrect step counts during driving.

[0185] The step count algorithm can have an accuracy of ±10% or ±12 steps per minute, whichever is higher, compared to the manual count of steps with respect to step count. The step count algorithm can have an accuracy of ±3% of steps when measured over 1,000 or more simulated steps and compared to a known step reference over an input range of 80 - 150 steps per minute or 80 - 180 steps per minute. In various examples, the step count algorithm can have an accuracy greater than the JIS S72000 - 1993 Japanese pedometer standard incorporated herein by reference.

[0186] Table 15 shows step count values as output by a comparison algorithm that analyzed acceleration data at various step rates.

[0187]

Table 15

[0188] Table 16 shows step count values output from the step count algorithm according to the present disclosure that analyzed acceleration data at various step rates.

[0189]

Table 16

[0190] Table 17 shows step count values output from the step count algorithm according to the present disclosure that analyzed acceleration data at various step rates while facing a 45° direction during measurement.

[0191]

Table 17

[0192] Tables 16 and 17 include substantially similar results showing that the orientation of the patch can have a minimal effect on the step count.

[0193] Table 18 shows a summary of various metrics from Tables 15 to 17 calculated over a range of 80 to 150 steps per minute or 80 to 180 steps per minute. The bias, absolute error, and error variation are lower for the step count algorithm according to the present disclosure than for the comparison algorithm. Further, the step count algorithm according to the present disclosure improves the overall performance of the wearable device.

[0194]

Table 18

[0195] Overall, the step count algorithm according to the present disclosure provides a more accurate step count, measured by the number of data points having an accuracy of ±3% or less.

[0196] Figure 14 shows a plot of the reported step count rates of various patients as output by various pedometers and wearable devices including a comparison algorithm and the step count algorithm according to the present disclosure. Patients 1 to 12 wore the wearable device. As shown, most devices functioned well at 100 steps per minute. However, the step count algorithm according to the present disclosure on the wearable device was superior to other devices including the comparison algorithm at a walking pace of 50 steps per minute while minimizing false step counts from the drive.

[0197] Variations in sampling speed can occur if the accelerometer does not have an external clock (X-Tal) and there is no trim setting. In various examples, there can be some variation in sampling speed across various wearable devices. Variations across various wearable devices can lead to a perceived shift in the input frequency (e.g., step rate) and thus potentially be reported as different step rates. The step count algorithm can incorporate the sampling speed into the step rate calculation.

[0198] Boundary effect

[0199] A wearable device can handle discontinuous data such as discontinuous data 1500 as shown in FIG. 15, including frames 1502 of physiological data and frames 1504 of the patient's ingestible sensor data scattered in the time gap 1506 between frames 1504 of the ingestible sensor data. For example, the wearable device can receive the ingestible sensor data 1504 continuously with the physiological data 1502. Discontinuous data can create somewhat inaccurate readings due to boundary effects caused by switching from one type of data to another (e.g., from physiological data to ingestible sensor data and / or from ingestible sensor data to physiological data), which can result in inaccurate physiological metrics (e.g., step count, heart rate, heart rate variability, body angle).

[0200] For example, FIG. 16 shows a first sub-frame of acceleration data on the left and a second sub-frame of acceleration data on the right. The first and second sub-frames are part of a single frame received discontinuously by the wearable device. As shown, the single frame can be a 14-second frame of accelerometer data, and each frame can be divided into smaller sub-frames (e.g., a 7-second portion of the 14-second frame), thereby improving the accuracy of the accelerometer data and facilitating serial communication of different data types.

[0201] Since sub - frames may be received and processed separately, boundary effects can occur at the start and end of each frame. The circles in Figure 16 indicate the level crossings that are counted by the step - count algorithm to obtain half - steps. Missing level crossings at sub - frame boundaries can lead to missing half - steps (e.g., inaccurate step counts). As shown in Figure 16, level crossings are overlooked as a result of boundary effects and the formation of discontinuous data between the end 1602 of the first sub - block (e.g., near sample index 90) and the start 1604 of the second sub - block (e.g., near sample index 0). In various examples, a level crossing can be a zero - crossing (e.g., the threshold level is zero) or a crossing further from the zero - crossing than the zero - crossing (e.g., the threshold is a non - zero number).

[0202] To handle boundary effects, various countermeasures can be taken. As discussed herein, step counting may be based on counting level crossings (e.g., one level crossing is counted as a half - step), and heart rate determination and heart rate variability can be determined based on counting peaks. An upward level crossing can be defined as going from a negative value to a positive value on the Y - axis until, or beyond, an upward threshold. A downward level crossing can be defined as going from a positive value to a negative value on the Y - axis until, or beyond, a downward threshold. To handle boundary effects, one measure is that if the last level crossing of the first sub - frame and the initial level crossing of the second sub - frame are of the same type (i.e., both upward or both downward), the step - count algorithm can increment the step count by a half - step. Further, the step - count algorithm may include an extended - precision value of the step count, which can be a factor for half - steps in step - rate calculation.

[0203] FIG. 17 shows an example of boundary effects in a frame of accelerometer data that can affect step counts when discontinuous data is received by a wearable device. As shown, the first sub-frame and the second sub-frame are each 7-second portions of a 14-second data block of total acceleration data. The circles in FIG. 17 indicate level crossings at which counted half-steps are obtained. By not counting partial half-steps 1706 at the start of the first sub-frame and / or at the end 1708 of the second sub-frame, an inaccurate step count (e.g., an under-estimation of the step count) can result.

[0204] To handle boundary effects, if there is a change in the slope of physiological data (e.g., a change in the sign of the slope calculated as x[n] - x[n - 1]) before the first level crossing or after the last level crossing in a sub-frame or frame, the step count algorithm can add a half-step. Region 1810 in FIG. 18 indicates a slope change. In response to the slope change, the step count algorithm can add a half-step. In general, measures for handling boundary effects can be applied to other devices that similarly handle different types of data continuously, resulting in the collection of discontinuous data. Further, what is collected to handle boundary effects in accelerometer data can also be applied to other types of physiological data, such as ECG data.

[0205] To show the data of the step count algorithm, a wearable device including the step count algorithm was used to output the step count via firmware, and the acceleration data from the wearable device was also post - processed in MATLAB to determine whether steps might have been missed. The wearable device was collecting output values (e.g., physiological metrics) derived from the accelerometer data and raw acceleration data. The MATLAB model analyzed the raw acceleration data. As shown in Figure 19, the step count value output from the step count algorithm processed by the processor of the wearable device was in complete agreement with the MATLAB model that post - processed the raw acceleration data from the wearable device on the remote device.

[0206] Furthermore, Figure 20A shows the total activity output from the step count algorithm over a long period of time (the step rate is displayed above the data of steps per minute (e.g., 30, 60, 120, 150, 180, 210). The threshold of the total activity can be set based on the lowest step rate to be detected and measured by the wearable device. For example, to detect a step rate of 60 steps / min and ignore step rates of 30 steps or less, a threshold within the range of 0.03 - 0.28 can be set based on the data shown in Figure 20A. Figure 20B shows the raw acceleration data from the accelerometer at various step rates on the left (the step rate is displayed above the data of steps per minute (e.g., 30, 60, 120, 150, 180, 210)) and the box - car filtered acceleration data on the right. The sampling frequency was 12.5Hz, the Nyquist frequency was 6.25Hz, the box - car filter length was 2, and the 3dB cut - off was at 3.2Hz. As shown for a step rate of 210 steps / min, the box - car filter might obscure a part of the steps of the data (e.g., counting 1 out of 2 steps) due to the filter length and the frequency of the measured steps. However, a sufficient amount of signal passes through the box - car filter to be measured at 210 steps / min.

[0207] Body angle

[0208] Wearable device 102 may include a function for automatically determining the orientation of the wearable device with respect to the patient's body using the detected physiological data. The determination may not require the patient to initialize and / or calibrate the wearable device 102. Thus, the wearable device 102 can be installed in various orientations, and therefore, the wearable device 102 may not require accurately positioning the wearable device 102 on the patient's skin in a specific position and / or orientation. For example, the wearable device 102 may be right-side up, upside down, or in other orientations.

[0209] The body angle algorithm can determine the patient's body angle without input from the patient, which is typically used to initialize the pedometer. The body angle algorithm can further be used to determine whether the wearer is asleep and / or lying down, as described herein. Since the patient cannot walk while lying down, the body angle algorithm can enable the wearable device 102 to reduce power consumption while the patient is asleep and / or lying down. Additionally, the body angle algorithm can enable efficient body angle determination after a power outage in the wearable device 102.

[0210] The body angle algorithm can receive accelerometer data and can be distributed across the wearable device 102 and the remote device for execution by the control circuit. For example, the body angle algorithm can be stored in the memory 112 and utilized by the processor 111 to convert accelerometer data received from the accelerometer 122 into physiological metrics such as body angle. The body angle algorithm can enable orientation determination without active calibration of the wearable device.

[0211] In various examples, the body angle algorithm can be stored and calculated on the remote device, and the accelerometer data used to calculate the body angle can be stored for a longer time, during which the time frame for excluding potentially incorrect body angle values increases, thus providing improved accuracy.

[0212] Determination of the body angle can depend on a reference vector that can be derived from the average acceleration data for each dimension from the accelerometer. The reference vector can correspond to the orientation of the wearable device when the patient is upright (e.g., walking, standing up), while the body angle can be the projection of the instantaneous average acceleration vector from the acceleration data onto the reference vector. As used herein, "lying horizontally" means the patient's position associated with a body angle of 0 degrees, while "upright" means the patient's position associated with a body angle of -90 degrees.

[0213] The reference vector can be output as a unitless quantity in floating point (one numerical value for each of the X, Y, Z dimensions), and the body angle can be output in degrees. The reference vector can be updated once per measurement period after the number of measurement periods exceeds the ACC BA Num Records parameter. The body angle can be calculated once per measurement period and can depend on the last updated reference vector.

[0214] The reference vector calculation can use a qualified ACR that includes a step rate within a selected range (e.g., between the parameters ACC BA Min Step Thr and ACC BA Max Step Thr) as input. Thus, in the reference vector calculation, since the patient is walking at a step rate within the selected range, it can be assumed that the patient is upright. The qualified ACRs are binned based on their average acceleration data. The binning can be performed independently for each of the axes (e.g., X, Y, Z) of the accelerometer data. Next, each selected bin of the axis having the most accurate record (which can be above "ACC_MIN_MODE") can be set as the reference vector.

[0215] If the wearable device has not saved and / or received sufficient qualified ACRs to set a reference vector, under the nominal assumption that the X-axis of the accelerometer exactly coincides with gravity when the patient is upright, the wearable device can use a default vector (e.g., {-1,0,0}). In an example where the patient installs the wearable device upside down on the body and a sufficient number of qualified ACRs are not collected (e.g., the wearable device is installed and the patient is lying on their side), the wearable device can invert the reference vector (e.g., {1,0,0}). If most of the ACRs exceed a threshold, e.g., have an x-axis value exceeding 0.8g and there are at least 3 ACRs, the wearable device can invert the reference vector. For example, the wearable device can assume that the wearable device is installed upside down.

[0216] The reference vector update can be frozen (e.g., no further updates) when the bin count reaches the bin count threshold (e.g., ACC_MAX_MODE) on any axis. Freezing the update can optimize the memory usage so that the bin count can be stored as an 8-bit integer. Assuming that the orientation of the wearable device can be relatively fixed with respect to the user's body (excluding some possible variations due to skin deformation), freezing the reference vector may not affect the accuracy of the reference vector.

[0217] As described herein, the body angle algorithm can calculate a reference vector that does not include the patient's position and / or can orient the wearable device to a selected position and / or orientation. In this way, the wearable device is easier for the patient to use and can automatically continue to determine the body angle in the event of a power outage.

[0218] The body angle algorithm can be configured to balance memory and the accuracy of the reference vector as needed. For example, another parameter, ACC_NUM_BINS, can be used to trade off the memory requirements for accuracy. In this way, the examples of the present disclosure can enable a reduction in chip size, power consumption, and / or clock speed.

[0219] Figures 21A - 21D show an example of generating a reference vector by filling bins with ACR. The wearable device can be configured to perform reference vector calculations. At startup of the wearable device (e.g., initialization), the reference vector bins can be emptied. The number of bins can be based on default compile-time parameters. In various examples, there may be 40 reference vector bins.

[0220] Referring to FIG. 21A, an initial state for reference vector determination is shown where the reference vector bin is empty. The default 40 reference vector bins are shown for axes X, Y, and Z. Acceleration data (e.g., ACR) where the step count exceeds "ACC BA Min Step Thr" and is less than "ACC BA Max Step Thr" can be regarded as eligible records for reference vector calculation and added to the reference vector bin. When an eligible record is received, the body angle algorithm can calculate the average result of the acceleration data (e.g., a packet of data). That is, the body angle algorithm can calculate the X Bin# bin, Y Bin# bin, and Z Bin# bin based on MeanX, MeanY, and MeanZ in Equation 13. The Y Bin# bin and Z Bin# bin are calculated in the same way as the X Bin# bin.

[0221]

Number

[0222] The body angle algorithm can calculate the X Bin# bin, Y Bin# bin, and / or Z Bin#The count in the bin can be incremented. Referring to FIG. 21B, the implementation state of the reference vector bin is shown. As shown, the count of eligible acceleration data in the reference vector bin is presented. To determine the reference vector, the body angle algorithm can evaluate the reference vector bin for each axis and determine which reference vector bin for each axis contains the most counts relative to the other reference vector bins. In FIG. 21B, since there is only one eligible record in the reference vector bin for each axis, the reference vector may not have been calculated yet by the body angle algorithm. The body angle algorithm may only calculate the reference vector when a threshold number of records has been reached (e.g., ACC BA Num Records). Waiting for the threshold number of records can increase the accuracy of the calculated reference vector. Additional eligible records received can be added to the reference vector bin.

[0223] Referring to FIG. 21C, a second eligible record is received and implemented in the reference vector bin. There is a tie in the reference vector bin for the Y axis. In an example where there is a tie in the reference vector bin, the first reference vector bin that reaches the count is selected. However, the threshold number of records (e.g., ACC BA Num Record) has not yet been reached (e.g., less than 3 eligible records). Therefore, the reference vector bin has not been selected for reference vector calculation.

[0224] Referring to FIG. 21D, a third eligible record has been received and implemented in the reference vector bin. The threshold number of records (ACC BA Num Records) has been reached. Therefore, the body angle algorithm can select the reference vector bin with the highest count on each axis (indicated by the shaded bin), and the body angle algorithm can calculate the reference vector from the selected bin. As shown, the body angle algorithm selected XBin = 0, YBin = 0, and ZBin = 1. Thereafter, the body angle algorithm can calculate the reference vector from Equation 14. The reference vector Y and the reference vector Z can be calculated in a similar manner as the reference vector X.

[0225]

Number

[0226] The reference vector can be a combination of the reference vectors of each axis. For example, the reference vector can be output as {reference vector X, reference vector Y, reference vector Z}. Since additional eligible records are received and implemented in the reference vector bin, the counts in the reference vector bin may change, and as a result, new maximum values may be obtained within each axis. Therefore, the reference vector can be recalculated (e.g., updated) after each eligible record is received. After the threshold amount of eligible records is received (ACC_MAX_MODE), the reference vector may be frozen and not recalculated.

[0227] After calculating the reference vector or based on the default reference vector, to determine the patient's body angle, the body angle algorithm can calculate the normalized projection of the average acceleration vector onto the reference vector according to Equation 15.

[0228]

Number

[0229] According to Equation 15, the acceleration vector aligned with the reference vector can be at a body angle of -90 o (e.g., upright). The acceleration vector offset radially from the reference vector can be at a body angle of 0 degrees (e.g., lying on side) or 90 degrees (e.g., upside down). The body angle can be quantified by a body angle algorithm or other software (embedded in a wearable device and / or a remote device) and mapped to one of the possible states. In various examples, the possible states can be only the four of upright, tilted, lying on side, and upside down. Thus, the body angle algorithm can be used by a wearable device to reduce the power consumption (e.g., the frequency of acceleration measurement) in a particular state (e.g., lying on side) in which the patient is unlikely to walk in that particular state.

[0230] Heart rate

[0231] The heart rate of a patient can be determined by measuring the electrical activity of the heart caused by myocardial depolarization and repolarization during the cardiac cycle. The electrical activity can be detected by placing electrodes on the patient's body and detecting an ECG signal (voltage vs. time). The ECG signal typically includes, among other things, a P wave, a QRS complex, and a T wave. The P wave represents atrial depolarization and typically occurs in less than 80 milliseconds (ms). The QRS complex is a combination of a Q wave (a downward deflection after the P wave), an R wave (an upward deflection after the Q wave), and an S wave (a downward curvature after the R wave) and typically corresponds to depolarization of the right and left ventricles of the human heart and contraction of the large ventricular muscle. The QRS complex typically occurs in 80 ms to 100 ms and typically has the largest amplitude in the ECG signal represented by the R wave peak. The T wave occurs following the QRS complex and typically represents ventricular repolarization, which can occur over 160 ms.

[0232] The method of determining the heart rate can focus on R-wave peak detection in the ECG data, and it is possible to reliably assume periodic and continuous data. For example, the patient's heart rate metric can be calculated according to Equation 16. As used herein, the term "heart rate" means the median heart rate unless otherwise stated. The average heart rate can also be calculated, but the median heart rate is the typical output.

[0233] [Number]

[0234] The R-R interval refers to the time between two adjacent R-wave peaks in the ECG signal. However, discontinuous data, including ingestible sensor data and frames of physiological data, can pose challenges when determining the patient's heart rate from the ECG data. That is, handling burst data from wearable devices and accurately determining the heart rate from the ECG data can present challenges.

[0235] The heart rate algorithm can receive the ECG data and be distributed across the wearable device 102 and the remote device for execution by the control circuit. For example, the heart rate algorithm can be stored in the memory 112 and utilized by the processor 111 to convert the ECG data into physiological metrics, such as step counts, etc. In various examples, the vector coprocessor portion of the heart rate algorithm can be stored in the memory 112 of the wearable device and executed on the wearable device 102, and the processor portion of the heart rate algorithm can be stored in the memory of the remote device and executed on the remote device. Processing the ECG data on the patch can reduce the data transferred to the remote device for further processing.

[0236] FIG. 22A shows a data example of a comparison algorithm for determining a heart rate from ECG data in which large data blocks are missing because the patient is asleep or at rest over a period of time, as shown by the patient's body angle vs. time in FIG. 22B (0 degrees corresponds to the patient lying horizontally). The large missing data blocks were removed by filtering using a comparison quality filter. FIG. 22C shows three frames of the raw ECG signal removed by filtering with a comparison quality. However, as shown, the heartbeats are still observable in the raw ECG signal.

[0237] To obtain an ECG metric, referring to FIG. 15, the physiological data 1502 may include ECG data for an ECG event period during a time gap 1506. The ingestible sensor data 1504 can be received between ECG data (e.g., during an ECG measurement interval). An ECG data frame can be a period of ECG signal acquisition, and a sub-frame can be part of a frame. In various examples, each frame includes four sub-frames.

[0238] A heart rate (HR) algorithm for processing ECG data may include the parameters of Table 19.

[0239]

Table 19

[0240] The quality metric of the ECG data can be calculated and used to filter the ECG data that can be used for a heart rate metric that can improve the accuracy of the heart rate metric calculated from noisy ECG data. In large-scale damaged ECG data, it may not be possible to accurately identify the R-wave peaks and their positions within the ECG data, resulting in an inaccurate heart rate metric. Therefore, large-scale damaged ECG data can be ignored and / or discarded rather than outputting and / or displaying an incorrect heart rate to the patient.

[0241] The HR algorithm can generate outputs such as for each ECG data frame, e.g., (i) a heart rate metric in beats per minute and (ii) a flag indicating whether the heart rate metric reported within the corresponding frame is valid (e.g., the flag is set to 1 if the measurement is valid and 0 otherwise, i.e., vice versa). The HR algorithm can also generate other auxiliary metrics that can be used by the wearable device and / or the remote device.

[0242] FIG. 23 shows a flowchart for receiving and processing ECG data. That is, the ECG signal is received from the electrodes of a wearable device placed on a patient. The raw ECG signal can be processed in the analog processing block 2302 and output as raw ECG data. The raw ECG data can be input to the processing block 2304 for processing by the HR algorithm. The HR algorithm can process the ECG data in the vector coprocessor 2306 (e.g., a vector microcoprocessor, e.g., a dual-core DSP processor, etc.) and the processor 2308 (e.g., an ARM Cortex™ M3 processor). The vector coprocessor 2306 and the processor 2308 can be located in the same location on the wearable device or one can be on the wearable device and one can be on the remote device. The vector coprocessor can be a vector microcoprocessor on an ASIC and the processor can be a high-performance reduced instruction set computing machine processor on an ASIC. The processing block 2304 can extract features from the data and output metrics such as, for example, the heart rate and / or other metrics.

[0243] In the comparison algorithm, the processing of the ECG data is not performed by the vector coprocessor 2306, and the raw ECG data would have been input to the processor 2308. However, the HR algorithm according to the present disclosure processes the ECG data in the vector coprocessor 2306. That is, the vector coprocessor 2306 enhances the raw ECG data received from the analog processing block 2302 and inputs the enhanced ECG data to the processor 2308, where features can be extracted from the enhanced ECG data. That is, the processing of the raw ECG data can be divided across the vector coprocessor 2306 and the processor 2308. That is, the vector coprocessor 2306 can denoise the raw ECG data by converting it into enhanced ECG data having emphasized R-wave peaks that can be more easily identified and / or located when calculating the heart rate metric. For example, the enhanced ECG data may require less processing by the processor 2308 and / or a different processor to identify and locate the R-wave peaks.

[0244] The vector coprocessor 2306 can, if desired, reduce the sampling rate of the ECG data or output enhanced ECG data at the same sampling rate as the raw ECG data. For example, the vector coprocessor 2306 can receive raw ECG data sampled at a first frequency (e.g., 256 Hz) and generate enhanced ECG data at the same first frequency (e.g., 256 Hz) or a different second frequency less than the first frequency (e.g., 64 Hz). By using the vector coprocessor 2306 to create enhanced ECG data, the efficiency in downstream filtering operations can be increased, the amount of data transferred can be reduced, and the efficiency of memory usage in the processor 2308 can be increased. By using the vector coprocessor 2306 and the processor 2308, further flexibility in the hardware design of the wearable device and the impact on the unmodified side, if any, can be minimized to enable modification of the vector coprocessor 2306 or the processor 2308.

[0245] Table 20 presents various programmable parameters for use with the HR algorithm according to the present disclosure.

[0246]

Table 20

[0247] When the acquisition of the ECG signal is started (e.g., controlled by a programmable parameter of the ECG event interval), the vector coprocessor 2306 can operate on the frame of the ECG data while maintaining the state of the filtering operation across the processing frame boundaries until the acquisition of the ECG signal is completed (e.g., controlled by a programmable parameter of the ECG event duration). For example, it can operate on a frame of ECG data (e.g., 512 samples at 256 Hz). The state of the filter operation can be reset at the start of every acquisition of the ECG signal. For example, the vector coprocessor 2306 can receive raw ECG data and enhance the ECG data through a series of linear and / or non-linear filtering operations, such as a series of filtering operations illustrated in FIG. 24 and described herein.

[0248] As shown in FIG. 24, in order to enhance the raw ECG data, the raw ECG data can be processed through a high-pass filter by the vector coprocessor 2402. The high-pass filter can suppress low-frequency noise sources, such as baseline drift and motion artifacts. The high-pass filter can be implemented as a FIR filter (e.g., 31 taps), and the degree of response is as shown in FIG. 25, and the parameters are summarized in Table 21.

[0249] [Table 21]

[0250] Returning to FIG. 24, the high-pass filtered ECG data can be processed through a low-pass filter 2404 to suppress high-frequency noise sources, such as 60 Hz power line interference. The low-pass filter can be implemented as a FIR filter (e.g., 31 taps), and the degree of response is as shown in FIG. 26, and the parameters are summarized in Table 22.

[0251] [Table 22] Table 22: Design Parameters of the Low-Pass Filter

[0252] Returning to FIG. 24, the low-pass filtered ECG data can be processed through a downsampling filter 2306. The downsampling filter can reduce the sampling rate of the ECG data, thereby reducing the processing cycles required to process the ECG data and the size of the ECG data in memory. For example, the downsampling filter can remove one out of two samples, two out of three samples, three out of four samples, or another amount of samples. In various examples, the low-pass filtered ECG data is not processed through the downsampling filter.

[0253] The ECG data can be processed through a derivative filter to further enhance the R-wave peak and sharpen (increase the gradient) the features at the R-wave peak of the ECG data 2408. The derivative filter can process the ECG data using a FIR filter (e.g., 5 taps). The coefficients of the derivative filter can be set to a reduced version of [0.5, 0, 0, 0, -0.5]. The derivative filter can be implemented with a degree of response as shown in FIG. 27. The stopband frequencies of the preceding high-pass and low-pass filters are shown as dashed lines in FIG. 27 for reference.

[0254] Returning to FIG. 24 again, the derived ECG data can be processed through a rectification filter (i.e., the absolute value of the ECG data) to make the polarity of the R-wave peak deterministic (i.e., always positive) 2410. The rectification filter can remove the ambiguity related to the polarity of the ECG data. The rectification filter can prepare the ECG data for the subsequent boxcar averaging step. In various examples, the rectification filter can be the only non-linear filtering operation performed by the vector coprocessor.

[0255] The corrected ECG data can be processed through a boxcar filter 2412. For example, the corrected ECG data can be averaged using a 24-tap boxcar filter, and all coefficients are set to a reduced version of 1 / 24. The boxcar filter can boost, localize, and / or isolate the QRS complex and can further enhance the R-wave peak. The data output from the boxcar filter can be enhanced ECG data, which can be sent to a processor. The boxcar filter can be implemented with a degree of response as shown in FIG. 28.

[0256] In this way, by processing the ECG signal in a vector coprocessor prior to the processor, the processing cycles required in the processor, the clock speed of the processor, and / or the memory usage in the processor can be reduced. Further, the enhancement of the ECG data can include a computing engine optimized for performing high-efficiency signal processing tasks. These signal processing functions can be hard-coded in logic that can be more than 10 times more efficient compared to software-based algorithms implemented in software executed by the processor 111 or other microcontroller units. The efficiency can be a reduction in chip size, power consumption, and / or clock speed. Further, the heart rate algorithm can maintain a certain level of programmability but utilize an execution unit that is optimized computing. The HR algorithm enables a wearable device to be placed on a patient seamlessly and still obtain accurate heart rate metrics. For example, depending on the location of the wearable device on the patient's body, the ECG signals detected by the wearable device can have a similar overall structure, but the amplitudes of the ECG signals can vary between locations. The differences in the amplitudes of the ECG signals can be explained by adjusting various thresholds in the HR algorithm.

[0257] Referring to FIGS. 29A to 29G, an example of raw ECG data processed by a vector coprocessor including downsampling is presented. FIGS. 29A to 29G visually show ECG data frames (1 frame = 14 sec) collected from a patient wearing a wearable device on the body and at rest. FIG. 29A shows the raw ECG data, and FIG. 29B shows the high-pass filtered ECG data after processing the raw ECG data from FIG. 29A through a high-pass filter. FIG. 29C shows the low-pass filtered ECG data after processing the high-pass filtered ECG data from FIG. 29B through a low-pass filter. FIG. 29D shows the downsampled ECG data after processing the low-pass filtered data from FIG. 29C through a downsampling filter. FIG. 29E shows the differentiated ECG data after processing the downsampled ECG data from FIG. 29D through a derivative filter. FIG. 29F shows the corrected ECG data after processing the differential ECG data from FIG. 29E through a correction filter. FIG. 29G shows the enhanced ECG data after processing the corrected ECG data from FIG. 29F through a boxcar filter.

[0258] Referring to FIGS. 30A to 30F, an example of raw ECG data processed by a vector coprocessor without downsampling is presented. FIGS. 30A to 30G visually show ECG data frames (1 frame = 14 sec) collected from a patient wearing a wearable device on the body and at rest. FIG. 30A shows the raw ECG data, and FIG. 30B shows the high-pass filtered ECG data after processing the raw ECG data from FIG. 30A through a high-pass filter. FIG. 30C shows the low-pass filtered ECG data after processing the high-pass filtered ECG data from FIG. 30B through a low-pass filter. FIG. 30D shows the differentiated ECG data after processing the low-pass filtered ECG data from FIG. 30C through a derivative filter. FIG. 30E shows the corrected ECG data after processing the differential ECG data from FIG. 30D through a correction filter. FIG. 30F shows the enhanced ECG data after processing the corrected ECG data from FIG. 30E through a boxcar filter.

[0259] The enhanced ECG data output of the vector coprocessor can be output at 24-bit resolution. Due to memory constraints in some processors, each ECG data frame of the ECG data can be normalized to conform at 16-bit resolution, and the resulting shift factor (e.g., NR_shift) can be saved and used in downstream processing. The shift factor can be calculated based on the maximum value (Max) observed within the frame, which may also be calculated by the vector coprocessor.

[0260] Referring to FIG. 31, an example of normalizing ECG data is presented. In various examples, the vector coprocessor can process data as a first number of bits (e.g., 24 bits), and the processor can process the data as a second number of bits (e.g., 16 bits) that is smaller than the first number of bits to save memory. To normalize the data from the vector coprocessor to the processor, the number of bit shifts (e.g., shift factor) required to align to the least significant bit (e.g., bit 23) is determined in the enhanced ECG data. As shown, the shift factor for the ECG data frame is calculated to be 5 to normalize the maximum value observed in the ECG data frame. The instruction for calculating the shift factor can be "(INT32 EcgFileRead::Normp24(UINT32 inp32)". Then, a shift (e.g., left shift) is performed based on the shift factor and saved to memory. The least significant number of bits (e.g., 16 as shown in FIG. 31) is retained and passed to the processor. Normalization can be a way to combine various sub-frames of the ECG data, resulting in a shift between sub-frames.

[0261] Returning to FIG. 23, the enhanced ECG data from the vector coprocessor 2306 can be input to the processor 2308. The processor 2308 can identify and locate the R-wave peaks in the enhanced ECG data and convert the positions of the R-wave peaks into a heart rate metric. The processor 2308 can also calculate a quality metric that can be used to determine the validity of the output heart rate metric. By determining the validity of the output heart rate metric, it is possible to limit, if not prevent, the wearable device from outputting an inaccurate heart rate due to large-scale corruption of the input raw ECG data. The validity determination can be used downstream by the wearable device and / or a remote device to filter out and discard inaccurate output heart rate metrics.

[0262] Before starting to process the enhanced ECG data from the vector coprocessor 2306, the processor 2308 can wait for a certain amount of enhanced ECG data to be stored in the buffer over a certain period, as determined by programmable parameters (e.g., the ECG event period). For example, at an ECG sampling rate of 256 Hz and a nominal ECG event period of 14 sec, samples of the enhanced ECG data must be stored in the buffer by the processor 2308 prior to processing the enhanced ECG data. The buffer for the enhanced ECG data can be divided into sub-frames with partial overlap. For example, as shown in FIG. 32, the buffer can be divided into four sub-frames with partial overlap. The four sub-frames can each be 3.5 seconds of the enhanced ECG data. The sub-frames can be overlapped to avoid losing peaks for the processing of boundary effects. The last sub-frame within a frame may not have an overlap. For example, an overlap coefficient such as 0.125 can be used.

[0263] FIG. 33 shows a flowchart of the processing of enhanced ECG data in a processor. That is, the processor can use a peak finder (PF) algorithm and an adaptive thresholding (AT) algorithm to find peaks in the sub-frames divided by the buffer 3302. Peak finding can be based on finding pairs of rising and falling edges when a peak threshold level crossing is given. The peak threshold can be defined according to the AT algorithm described herein. The processor can use a peak finding (PF) algorithm as shown in FIG. 34. The PF algorithm and the AT algorithm can be sub-components of the HR algorithm.

[0264] If it is found that the number of consecutive samples exceeds the peak detection threshold and the local derivative is positive, it can be determined as a rising edge. If it is found that the number of consecutive samples is below the peak detection threshold, it can be determined as a falling edge. If it is found following a rising edge (e.g., a pair of a falling edge and a rising edge), it can be determined as a tentative peak. The PF algorithm only searches for level crossings and does not need to search for maxima, and thus peak refinement may be required as described herein.

[0265] Referring to FIG. 35A, after three consecutive samples are found after the threshold 3506, it is determined as a rising edge 3502. After three consecutive samples are found after the threshold 3506, it is determined as a falling edge 3504, and the peak is determined based on the pair 3502 of the falling edge 3504 and the rising edge.

[0266] The processor can also utilize the AT algorithm in conjunction with the PF algorithm to identify peaks within each subframe. The AT algorithm can include adapting (e.g., changing, adjusting) them dynamically until the peak thresholds (e.g., lower peak threshold L, upper peak threshold U) converge (i.e., result in substantially the same number or the same number of identified R-wave peaks), or until they stop converging because one or more end criteria are met. The AT algorithm can be initialized with data-dependent thresholds and can constitute the signal amplitude variation over the subframe.

[0267] For each subframe, the AT algorithm can calculate Equation 17.

[0268]

Equation

[0269] Since it may be necessary to initialize the filtering operation at the start of ECG signal acquisition, the first sample amount (referred to as the transient region) in the first sub-frame can be omitted to allow the filtering operation in the vector processor to converge. In various examples, the first sample amount is 60. The period of the transient region can be selected based on the total step response of all filtering operations in the vector processor. Thereafter, the AT algorithm can initialize the peak threshold. For example, the initial peak threshold can be based on statistical values of the ECG data, such as maximum, average, and / or standard deviation. The PF algorithm can calculate the number of peaks (nU) based on threshold U and the number of peaks (nL) based on threshold L while satisfying the conditions of Equation 18.

[0270]

Number

[0271] The threshold can be adjusted according to Equation 19, and the PF algorithm can recalculate nU and nL as long as the conditions in Equation 18 are still satisfied.

[0272]

Number

[0273] When the iteration converges, the AT algorithm can determine that the sub-frame is valid (i.e., nU = nL when the loop ends), and otherwise (e.g., number of iterations > maximum number of iterations) can determine that the sub-frame is invalid.

[0274] Referring to FIGS. 36A to 36E, it is an example of dynamically adapting the threshold in the ECG data using an adaptive thresholding algorithm. The thresholding algorithm can be a sub-component of the HR algorithm. In FIG. 36A, the threshold L is initialized as 20% of the maximum value in the ECG data, and the threshold U is initialized as 60% of the maximum value. The maximum number of iterations is defined as 10. Then, the first iteration of the number of peaks is calculated based on the initial peak thresholds U and L. That is, in FIG. 36A, based on the threshold U, there are 6 peaks, and based on the threshold L, there are 8 peaks. The AT algorithm evaluates Equation 18, confirms that the condition is satisfied, and then continues to dynamically adapt the peak thresholds U and L.

[0275] The thresholds U and L are dynamically adapted by the AT algorithm based on Equation 19. Then, the second iteration of the number of peaks nU and nL is calculated based on the respective adapted peak thresholds U and L. That is, in FIG. 36B, based on the threshold U, there are 6 peaks, and based on the threshold L, there are 8 peaks. The AT algorithm evaluates Equation 18, confirms that the condition is satisfied, and then continues to dynamically adapt the peak thresholds U and L.

[0276] The peak thresholds U and L are dynamically adapted as the second time based on Equation 19. Then, the third iteration of the number of peaks nU and nL is calculated based on the peak thresholds U and L adapted twice respectively. That is, in FIG. 36C, based on the threshold U, there are 6 peaks, and based on the threshold L, there are 7 peaks. The AT algorithm evaluates Equation 18, confirms that the condition is satisfied, and then continues to dynamically adapt the peak thresholds U and L.

[0277] The peak thresholds U and L are dynamically adapted as a third time based on Equation 19. Thereafter, the fourth iteration of the number of peaks nU and nL is calculated based on the peak thresholds U and L adapted three times respectively. Thereafter, that is, in FIG. 36D, based on the threshold U, there are six peaks, and based on the threshold L, there are seven peaks. The AT algorithm evaluates Equation 18, confirms that the condition is satisfied, and continues to dynamically adapt the peak thresholds U and L.

[0278] The peak thresholds U and L are dynamically adapted as a fourth time based on Equation 19. Thereafter, the fifth iteration of the peaks nU and nL is calculated based on the peak thresholds U and L adapted four times respectively. That is, in FIG. 36E, based on the threshold U, there are six peaks, and based on the threshold L, there are six peaks. The AT algorithm evaluates Equation 18 and determines that the condition is no longer satisfied because the number of peaks (nU) based on U is equal to the number of peaks (nL) based on L. Therefore, the AT algorithm stops the dynamic application of the peak thresholds U and L, and the PF algorithm defines the tentative peaks based on the adapted peak thresholds. Furthermore, since the number of iterations is less than the maximum number of iterations, the subframe is determined to be valid.

[0279] Returning to FIG. 33, the tentative peaks found from the PF algorithm can be integrated 3304. For example, the peaks found in all subframes can be counted, and the peaks found in the transition region of the first subframe can be discarded. In various examples, peak integration may not occur. The peaks found by the PF algorithm may include not only R-wave peaks but also additional peaks (e.g., T-wave peaks). Therefore, the tentative peaks must be adjusted to confirm and / or ensure that the peaks found correspond to the R-wave peaks.

[0280] The tentative peaks identified by the PF algorithm can be adjusted based on a maximum search 3306. For example, the peak search window can be defined based on the rising edge based on a peak threshold, and the maximum in the search window can be determined as the position of the peak. The peak search window starts at the position of the rising edge of the window and extends to a number of samples (e.g., 40) going forward (e.g., towards the paired falling edge). The number of samples can be defined to accommodate substantially all of the QRS complex period of interest (e.g., up to 120 ms). The PF algorithm can prevent the need for a reverse search and cannot determine the position of a peak that occurs after a peak that is actually nearby.

[0281] As shown in FIG. 35B, the search window 3510 can be defined based on the rising edge 3502. Thereafter, the adjusted peak 3508 window position can be determined based on a maximum search within the peak search window 3510.

[0282] Returning to FIG. 33, once the position of the peak is determined and adjusted so that the position corresponds to a maximum, the processor can eliminate false peaks 3308. For example, peaks that are closer to each other than a distance threshold (e.g., determined by a refractory period that can be 170 ms or more) can be eliminated. For example, if the positions of the peaks are scanned continuously and it is found that consecutive peaks are within 44 samples of each other, the peak with the higher amplitude can be retained and the other peak(s) can be eliminated. Further, peaks in the transition region can be eliminated.

[0283] The processor 3310 can reject peaks based on amplitude fluctuations. For example, in the case of a high-amplitude T-wave peak, the PF algorithm may identify the T-wave peak as a tentative peak that can occur as a bimodal amplitude distribution in the enhanced ECG data. To avoid determining the T-wave peak from the tentative peak as a valid R-wave peak, a bimodal amplitude detector can be activated by the processor. When a bimodal amplitude distribution is detected, the peak distribution can be analyzed, and only the peaks corresponding to the R-wave can be considered for the heart rate metric.

[0284] To determine whether bimodal amplitude exists in the enhanced ECG data, the bimodal amplitude detector adjusts the amplitude of the tentative peak of the shift coefficient and calculates the minimum peak amplitude A min and can calculate the maximum peak amplitude A max The peak amplitude can be binned into N b bins, and the bin range can be determined to dynamically cover the range of peak amplitudes (e.g., 0.8 minimum amplitude (A min ) 1.2 maximum amplitude (A max ). The bimodal amplitude detector can determine the bin n1 with the largest entry and the bin n2 with the second largest entry. The amplitudes A1 of bin n1 and A2 of bin n2 can be calculated. Next, the processor can determine whether the conditions (i)-(v) in Equation 20 are valid.

[0285]

Equation

[0286] When all of the conditions (i) to (v) of Equation 20 are valid, the bimodal amplitude detector can determine that the enhanced ECG data contains a bimodal amplitude distribution. In response to the determination of the bimodal amplitude distribution, the processor can hold the peaks corresponding to the valid R waves and remove the peaks corresponding to the T waves from the tentative peaks. For example, if A1 is greater than A2, the processor can hold the peaks in the enhanced ECG data having amplitudes within the first range corresponding to bin n1 of the maximum entry (e.g., 0.8A1 to 1.2A1). However, if A2 is greater than A1, the processor can hold the peaks in the enhanced ECG data having amplitudes within the second range corresponding to bin n2 of the second most numerous entry (e.g., 0.8A2 to 1.2A2). By the determination of condition (v), it can be ensured that there are sufficient peaks available for binning to create a reliable histogram. In various examples, N b = 10, thresh1 = 0.25, thresh2 = 1.3, thresh3 = 0.8, thresh4 = 15.

[0287] Furthermore, the bimodal amplitude detector can determine whether at least one of the following conditions is met: the number of entries in bin n2 is greater than or equal to the bin threshold; the difference between A1 and A2 is greater than or equal to the difference threshold; the number of entries in bins n1 and n2 is greater than the threshold portion of the total number of peaks; and n1 and n2 are not adjacent bins. In various examples, the bimodal amplitude detector can determine whether all of the conditions are met.

[0288] Referring to FIG. 37A, the provisional peaks are determined at the positions marked by circles in the ECG data 3702. The provisional peaks include both the R-wave peaks and the T-wave peaks. Thereafter, the amplitudes of the provisional peaks in FIG. 37A are binned into 10 bins, and the bin range covers the range of the peak amplitudes. The amplitude histogram output of the binned peak amplitudes is shown in FIG. 37B. Thereafter, it was determined that conditions (i) to (v) in Equation 20 were valid for the detected bimodal amplitudes, and it was concluded that the enhanced ECG data included a bimodal amplitude distribution. In response to the determination of the bimodal amplitude determination, peaks having amplitudes within the range of 80% to 120% of the peaks in bin 8 are retained, and other peaks are removed (for example, the peaks in bins 2 and 3 are removed). The remaining peaks from FIG. 37A that were not removed by the bimodal amplitude detector are marked by circles in the ECG data 3902 in FIG. 37C.

[0289] Peaks not removed by peak integration in step 3304, false peak removal in step 3308, and amplitude variation peak removal in step 3310 are determined to be valid R-wave peaks. The valid R-wave peaks can be used for the heart rate metric.

[0290] Examples of ECG data were modeled in MATLAB. Each example included a T-wave, and the amplitude of the T-wave varied between examples. The heart rate (based on the R-R interval) was kept constant at 80 beats per minute. The examples were processed with a comparative algorithm and the bimodal amplitude detector according to the present disclosure, and the heart rate metric was calculated based on the valid R-wave determination output. Table 23 shows the results of the comparative algorithm for determining the heart rate based on examples of ECG data, and Table 24 shows the results of the HR algorithm according to the present disclosure with bimodal amplitude removal.

[0291]

Table 23

[0292]

Table 24

[0293] As shown, the comparison algorithm definitely failed when the T-wave amplitude exceeded 0.6 mV. However, the bimodal amplitude detector according to the present disclosure rejected the T-wave so that an accurate heart rate metric could be calculated at T-wave amplitudes greater than 0.6 mV.

[0294] Furthermore, referring to FIG. 30G, it is an example of the enhanced ECG data from FIG. 30F processed by the processor. The peak threshold is shown as a horizontal solid line, the boundary of each frame is shown as a vertical dashed line, and the R-wave peaks determined to be valid are marked with circles.

[0295] Returning to FIG. 33, if the tentative peak is determined to be valid R-wave data, the HR algorithm can calculate the R-R interval of the enhanced ECG data 3312. The R-R interval can be calculated according to Equation 21.

[0296] [Number]

[0297] Based on the R-R vector interval calculation, the HR algorithm can calculate the average and median heart rates 3314. The average heart rate can be determined from the R-R interval according to Equation 22, and the median heart rate can be determined from the R-R interval according to Equation 23.

[0298] [Number]

[0299] [Number]

[0300] The enhanced ECG data obtained from discontinuous data by a wearable device may be susceptible to the influence of noise that may not be suppressed using signal processing associated with a vector coprocessor and a processor. Accordingly, a quality metric of the enhanced ECG data can be calculated and used to determine whether the enhanced ECG data is valid 3316. The quality metric calculation can be performed in parallel with the heart rate calculation in step 3314. The quality metric may include at least one of a peak spread, a median absolute deviation, and a quality score.

[0301] The quality metric can be used to determine (i) which R-wave peaks, if any, in an ECG data frame should be used for heart rate calculation, and (ii) whether a heart rate metric value should be presented to a patient. Valid R-wave data present in a valid frame of the enhanced ECG data can be used for heart rate calculation, and a heart rate metric value can be presented to a user based on the valid frame. While an invalid frame of the enhanced ECG data may not be used for heart rate calculation, a heart rate value calculated from an invalid frame may not be presented to a user. The quality metric can be used to determine whether a frame of the enhanced ECG data is valid based on a comparison of the quality metric to a quality threshold as described herein. The HR algorithm can ignore a frame or a frame of physiological data based on the comparison. In this way, the HR algorithm can accurately determine a physiological metric, such as a heart rate, from discontinuous data and reduce power consumption by not processing invalid frames during the calculation of the physiological metric.

[0302] The number of peak spreads (PS) can be calculated according to Equation 24 when n specified peaks in the i-th subframe are given. i is given.

[0303]

Equation

[0304] The median absolute deviation (MAD) can be calculated according to Equation 25 when the R-R interval (RR) and the median absolute deviation metric (median(RR)) are given. MAD can be a measure of the variation around the median.

[0305]

Number

[0306] The quality score (QS) can be calculated as the total number of sub-frames considered valid (e.g., a value in the range of 0 to 4 in an example including four sub-frames). As described herein, a sub-frame can be considered invalid for (i) non-convergence of adaptive thresholding and / or (ii) peak rejection by bimodal amplitude determination.

[0307] A frame can be considered valid if the following conditions (i) to (iii) in Equation 26 (e.g., comparison of a quality metric to a quality threshold) are valid.

[0308]

Number

[0309] The ECG MAD threshold, the ECG peak spread threshold, and the ECG quality threshold are shown in Table 19. In various examples, the MAD quality filter can be disabled by setting the programmable parameter ECG MAD threshold to 0.

[0310] As shown in FIG. 38, five frames of raw ECG data 3802 to 3810 are provided and processed by a vector coprocessor and a processor. That is, each frame of the raw ECG data 3802 to 3810 is processed by the vector coprocessor to enhance the ECG data, and the enhanced ECG data is processed by the processor to calculate the median heart rate metric and the quality metric. The ECG MAD threshold is set to 12, the ECG peak spread threshold is set to 4, and the ECG quality threshold is set to 3. The validity of each frame is determined according to Equation 26. The median heart rate metric and the quality metric are shown in Table 25.

[0311]

Table 25

[0312] As shown, the raw ECG data 3806 is invalid and may not be used in heart rate metric calculations, and the heart rate metric value based on the raw ECG data 3806 may not be displayed to the patient. The raw ECG data 3802, 3804, 3808, and 3810 are valid and can be used in heart rate calculations, and the heart rate values based on the raw ECG data 3802, 3804, 3808, and 3810 can be displayed to the patient.

[0313] Furthermore, the HR algorithm can utilize features extracted from the raw ECG data and / or the enhanced ECG data to determine whether the electrodes from the wearable device are in contact with the patient's skin or not. If the HR algorithm determines that the electrodes are not attached to the patient's skin, the HR algorithm can assert that the ECG data is invalid, and otherwise, the HR algorithm can assert that the ECG data is valid. A further example explanation of how the ECG data is used in this case is described in Attorney Docket No. PRTS-220PRV, which is hereby incorporated by reference into this specification again.

[0314] The HR algorithm according to the present disclosure can reduce the number of processing cycles during the execution of the HR algorithm and the size of the HR algorithm (e.g., code space). Therefore, the HR algorithm according to the present disclosure may require less power and memory to execute. For example, the HR algorithm according to the present disclosure can result in an 85% reduction in the number of processing cycles during the execution of the HR algorithm (e.g., from 3.9 million to 0.59 million) and a 46% reduction in code space (e.g., from 4.78 kB to 2.6 kB). The reduction in processing cycles and / or memory usage can enable additional features / algorithms to operate in a memory-constrained environment. The additional features and / or algorithms can be HRV measurement, respiration measurement, and / or IEM dual decoding operations. The reduction in processing cycles can reduce the power required to process the HR algorithm and enable high-speed processing of the HR algorithm. In various examples, the reduction in processing cycles can enable the operation of the processor at a lower clock speed, thereby further reducing the power required to process the HR algorithm.

[0315] The emulation of the processor employed in the firmware of the wearable device was compared with the MATLAB model of the processor, and both analyzed the enhanced ECG data from the MATLAB model of the vector coprocessor. The MATLAB model and the emulation yielded substantially the same heart rate calculation.

[0316] The emulation of the vector coprocessor and the processor employed in the firmware of the wearable device that received ECG data in binary format was compared with the MATLAB model of the vector coprocessor and the processor that analyzed the raw ECG data. The MATLAB model and the emulation of the processor yielded substantially the same heart rate metric value.

[0317] The HR algorithm was evaluated with respect to the ECG data of the MIT - BIH arrhythmia database (available at "http: / / www.physionet.org / physiobank / database / mitdb / ") using a comparison algorithm and the HR algorithm according to the present disclosure. There were 48 ECG data recordings (47 patients) in the MIT - BIH arrhythmia database, each 30 minutes long, from clinical settings. The MIT - BIH arrhythmia database is commonly used to evaluate QRS detection algorithms. Another noise trace is available for evaluating performance in a noisy environment.

[0318] The raw ECG data from the MIT - BIH arrhythmia database was processed with the waveform Database (WFDB) tool (available at "http: / / physionet.org / physiotools / matlab / wfdb - app - matlab / "). The ECG data processed by the WFDB tool was input into the MATLAB model of the HR algorithm according to the present disclosure, and the sensitivity and positive predictability were evaluated based on the annotated results of the ECG data processed only by the WFDB tool. The sensitivity was evaluated according to Equation 27 based on the number of true positives (TP) and the number of false negatives (FN).

[0319]

Equation

[0320] The positive predictability was evaluated according to Equation 28 based on the number of true positives (TP) and the number of false positives (FP).

[0321]

Equation

[0322] The results of the evaluation of records in the noise-free MIT-BIH arrhythmia database and the quality metrics turned off in the HR algorithm are shown in FIGS. 41 and 42. That is, the sensitivity results of the comparative algorithm and the HR algorithm according to the present disclosure are shown in FIG. 41. The overall sensitivity average averaged over all 48 records in the MIT-BIH arrhythmia database of the comparative algorithm was 93.6%, and for the HR algorithm according to the present disclosure, it was 97.9%. The sensitivity of the HR algorithm can be limited to 98% for the processing of ECG data within a frame.

[0323] The positive predictability results of the comparative algorithm and the HR algorithm according to the present disclosure are shown in FIG. 42. The overall positive predictability average averaged over all 48 records in the MIT-BIH arrhythmia database of the comparative algorithm was 90.1%, and for the HR algorithm according to the present disclosure, it was 99.5%.

[0324] In the HR algorithm, the results of the average sensitivity averaged over all 48 records in the MIT-BIH arrhythmia database with added noise and the quality filter turned on are shown in FIGS. 43A to 43C. To add noise to the 48 records, noise traces were added separately with different scalings as described in "http: / / www.physionet.org / physiobank / database / nstdb / " to vary the signal-to-noise ratio (SNR). FIG. 43A shows the valid frames detected by the added noise based on the electrode operation, FIG. 43B shows the valid frames detected by the added noise based on the baseline variation, and FIG. 43C shows the valid frames detected by the added noise based on the muscle artifact.

[0325] The HR algorithm can be effective in the clinical setting. That is, the performance of the HR algorithm was verified on-site after being run on 10 patients who wore a wearable device near the torso for 24 to 48 hours. As a result, 13.7 days' worth of ECG data was collected. The wearable device performed an ECG measurement every 19 seconds and then acquired the ECG data.

[0326] The patients also wore a comparative heart rate monitor (CHRM) attached to the torso using standard ECG electrodes. The R-R intervals were recorded on the CHRM at 1-millisecond resolution, and the ECG data was provided continuously (e.g., not discontinuously) from the CHRM. The data obtained from the CHRM was post-processed offline (in 14-second blocks) to calculate the median heart rate. The median heart rate metric value from the CHRM data was compared with the median heart rate metric value from the wearable device after timing synchronization (based on cross-correlation) as shown in Table 26.

[0327]

Table 26

[0328] As shown, despite using discontinuous data, the HR algorithm according to the present disclosure functioned well compared to the CHRM ECG data.

[0329] The upper diagrams in each of FIGS. 44A to 44E show examples of ECG data collected using the HR algorithm of the wearable device and the CHRM for various patients. That is, FIG. 44A shows the results for Patient 2, FIG. 44B shows the results for Patient 3, FIG. 44C shows the results for Patient 4, FIG. 44D shows the results for Patient 8, and FIG. 44E shows the results for Patient 7. As shown in FIGS. 44A to 44E, the heart rate metric values output by the HR algorithm can be predictable and highly reliable during different activities. Further, the lower diagrams in each of FIGS. 44A to 44E show the step rate metric values output from the step count algorithm of the wearable device.

[0330] A wearable device combined with an HR algorithm can determine a heart rate metric value from ECG data with an accuracy of either ±10% or the higher of ± beats per minute within a heart rate range of 30 to 250 beats. The accuracy can be tested with respect to test waveforms with a QRS duration of 40 ms to 120 ms and a QRS amplitude of 0.2 mV to 2 mV from ANSI / AAMI EC13:2002 Cardiac Monitors, Cardiac Monitors, heart rate meters, and alarms, Section 5 Test Methods. The wearable device can be configured to meet the line frequency voltage tolerance requirements (Section 4.2.6.2 of ANSI / AAMI EC13:2002) and the drift tolerance requirements (Section 4.2.6.3 of ANSI / AAMI EC13:2002). Further, during the accuracy test, more than 95% of the ECG data should be marked as valid. It can be tested with respect to test waveforms with a QRS duration of 40 ms to 120 ms and a QRS amplitude of 0.2 mV to 2 mV from ANSI / AAMI EC13:2002 Cardiac Monitors, Cardiac Monitors, heart rate meters, and alarms, Section 5 Test Methods. The wearable device can be configured to meet the line frequency voltage tolerance requirements (Section 4.2.6.2 of ANSI / AAMI EC13:2002) and the drift tolerance requirements (Section 4.2.6.3 of ANSI / AAMI EC13:2002). Further, during the accuracy test, more than 95% of the ECG data should be marked as valid.

[0331] Figures 45A - 45D show examples of how heart rate monitoring can be implemented with additional settings such as during an active period. The HR algorithm can be accurate in a state of rest / sleep and limited mobility, with limited measurement dropout. As shown, the HR algorithm can detect the heart rate while the patient is performing some activity, and the patient may not need to be completely stationary. For example, Figure 45A shows the heart rate versus step rate as the step rate increases. Figure 45B shows that data loss during patient activity, if any, is minimal. Figure 45C shows the ECG during patient activity, and Figure 45D shows the ECG data when the patient is inactive.

[0332] Raw ECG data, enhanced ECG data, and metrics can be stored in an ECG data record in memory, such as in the memory of a wearable device and / or the memory of a remote device. An example of ECG data is presented in Table 27.

[0333]

Table 27

[0334] The wearable device can include a scheduler (e.g., a software module external to the algorithms described herein) that can start and stop ECG data acquisition according to ECG event interval and ECG event duration programmable parameters. Specifically, the ECG signal can be acquired periodically every second of the ECG event interval for determination of the duration in seconds of the ECG event period (e.g., at a fixed sampling rate of 256 Hz).

[0335] Heart rate variability

[0336] Heart rate variability (HRV) is the variation in the time intervals between heartbeats, measured by the variation in the R-R intervals. HRV has been shown to have clinical significance in both cardiac and psychiatric use cases. For example, abnormal HRV has been shown to be a predictor of mortality after myocardial infarction, depression, anxiety disorder, bipolar disorder, and schizophrenia. HRV can also be used for stress quantification, sleep stage identification, and estimation of respiratory rate.

[0337] To determine HRV metrics, it may basically be necessary to collect a large amount of ECG data over a few minutes. The extended amount of ECG data can be smoothed and averaged, and then the HRV metrics can be determined.

[0338] The HRV algorithm can receive ECG data and can be distributed across the wearable device 102 and the remote device for execution by the control circuit. For example, the HRV algorithm can be stored in the memory 112 and utilized by the processor 111 to convert the received ECG data into physiological metrics, such as HRV metrics. The HRV algorithm can be stored in the memory of the remote device and process the ECG data of the remote device to convert the ECG data into physiological metrics. In various examples, the HR algorithm can be implemented on the ECG data of the wearable device, and the wearable device can output the resulting data to the remote device of the HRV algorithm to determine the HRV metric from the resulting data.

[0339] The wearable device and / or the remote device can calculate HRV from the ECG data. For example, the wearable device and / or the remote device can calculate HRV when the HRV mode is enabled via programmable parameters of the ECG HRV interval. When the HRV mode is enabled, the wearable device can measure the ECG signal and obtain the ECG data from the wearable device as described herein.

[0340] Returning to FIG. 15, the wearable device can perform an IEM (Ingestible Event Marker) sniff operation after each ECG frame in the physiological data 1506 while in the HRV mode. If no IEM activity is detected, the wearable device moves to the next ECG frame after each ECG HRV gap. If IEM activity is detected by the sniff operation, the wearable device can be veiled in the HRV mode and instead can be in the IEM detection mode.

[0341] The HRV metric can be a time domain metric, a frequency domain metric, a non-linear metric, or other types of metrics. For example, time domain metrics can include the interval between normal R-peaks (average N-N interval), standard deviation of N-N intervals (SDNN), root mean square of successive R-R interval differences (RMSSD), percentage of successive N-N intervals that differ by more than a threshold (e.g., 50 ms) (pNN50:P), HRV triangular index, and baseline width of the T-T interval histogram (TINN). Frequency domain metrics can include power in the low frequency band (LF power), power in the high frequency band (HF power), and ratio of LF power to HF power (LF / HF ratio). Non-linear metrics can include approximate entropy (ApEn), which can measure the regularity and complexity of a time series. The HRV metric can be calculated over a short period (several minutes) and / or a long period (24 hours).

[0342] However, in a discontinuous data environment, gaps between ECG data can pose challenges when calculating the HRV metric. Since the boundaries of ECG data frames may not start or end at the same point in the cardiac cycle, it can be difficult to accurately calculate the HRV metric by stitching together ECG data frames. Further, in examples where the HRV metric is at least partially calculated on a wearable device, it may be desirable to create a power-efficient algorithm to conserve battery (e.g., perform simple calculations, not perform complex operations such as FFT, and use integers instead of floating point operations).

[0343] The HRV mode can include the following parameters: HRV_Event_Interval (default 30 minutes); HRV_Num_Blocks (default 9); and HRV_Block_Gap (default 4 seconds).

[0344] Every HRV_Event_Interval seconds, the wearable device can enter the HRV mode, in which it can acquire discontinuous ECG signals (e.g., 14 - second frames). The HRV_Num_Blocks time with ECG signals can be separated by HRV_Block_Gap seconds. After all frames of the ECG signal, if IEM is successful, the wearable device can end the HRV mode. When ending the HRV mode, collect the ECG data from the acquired ECG signals, process it, and extract the relevant HRV metrics. This step can be passed to the backend (e.g., a remote device).

[0345] Referring to FIG. 46, to determine the HRV metrics, the HRV algorithm receives discontinuous data including frames of ingestible sensor data and frames of physiological data. The HRV algorithm analyzes the physiological data including the analyzed ECG data, the index of all detected R - peaks (RWV) in the ECG data, and impedance (IMP) data (e.g., another measurement) 4602. The ECG data can be processed by the HR algorithm according to FIG. 23. Then, returning to FIG. 46, the frames of the ECG data can be grouped into blocks 4604. For example, the number of frames grouped into blocks together can be set by the parameter HRV_Num_Blocks. The number of frames grouped together can be at least 2 and can have a default value of 9 frames. The frames in a block can be arranged continuously.

[0346] After that, the HRV algorithm can determine whether the number of frames in a block having a valid heart rate metric value is equal to or greater than a validity threshold 4606. The validity of each frame can be determined by the processor and according to Equation 26. In various examples, the validity threshold can be 8 (e.g., 90% of the entire block). If the number of frames in a block having a valid heart rate metric value is less than the validity threshold, the block can be skipped and the HRV metric may not be determined from the block. In this way, the HRV algorithm can reduce the power consumption of the wearable device by not processing invalid blocks of ECG data.

[0347] However, if the number of frames in a block having a valid heart metric value is equal to or greater than the validity threshold, the HRV algorithm can proceed to determine whether the impedance data before and / or after the block is valid 4608. If the nearest impedance data before and / or after the block is not valid, the block can be ignored and the HRV metric may not be determined from the block. For example, if the median of a moving window of consecutive impedance values (e.g., 5) is greater than an impedance threshold (e.g., 10 kOhm), the block can be considered invalid and the HRV metric may not be determined from the block. Next, after a single impedance measurement lower than the impedance threshold, the block can be used for the HRV metric. In this way, the HRV algorithm can conserve power when high impedance is measured (e.g., an electrode is detached from the skin) and can quickly return to calculating the HRV metric after the high impedance event has ended (e.g., the electrode is returned to the skin).

[0348] However, if the nearest impedance data before and / or after the block is valid, the HRV algorithm can process the block and reject frames that include outliers of the heart rate in the block of ECG data 4610. The outlier heart can be based on data with falsely identified R-peaks, or R-peaks with irregular intervals (e.g., arrhythmia). The outliers of the heart rate can be determined based on the median absolute deviation. Thereafter, the HRV algorithm can determine whether a majority of the frames in the block are good (e.g., do not include outliers of the heart rate) 4612. In various examples, the good threshold can be 8. If the number of good frames in the block is less than the good threshold, the block can be ignored and the HRV metric may not be determined from the block.

[0349] However, if the number of good frames in the block is greater than or equal to the good threshold, the HRV algorithm can aggregate the R-wave data from all good frames in the block of ECG data 4614. Thereafter, the aggregated R-wave data can be processed through an R-R cleaning algorithm 4616.

[0350] The R-R cleaning algorithm can include a merge twin interval algorithm, a split tall interval algorithm, an absorb short interval algorithm, and a bimodality detection algorithm (e.g., a bimodality amplitude detector as described herein). The R-R cleaning algorithm can be applied to the aggregated R-wave data on a processor on the wearable device and / or on a processor on a remote device. Further, the R-R cleaning algorithm can be applied at the frame level to reduce the number of outliers in the heart rate report.

[0351] The merge twin interval algorithm can integrate two short R-R intervals sandwiched between two long RR-intervals. For example, if Equation 29 is valid, two long R-R intervals (Xn -1 , Xn +2Two short R-R intervals (Xn, Xn +1 ) sandwiched between can be integrated into one R-R interval (Xn + Xn +1 ).

[0352]

Number

[0353] The split toll interval algorithm can split a toll R-R interval sandwiched between two short intervals into two intervals. For example, when Equation 30 is valid, one toll R-R interval (Xn -1 , Xn +1 ) sandwiched between two short R-R intervals can be split into two (two of Xn / 2).

[0354]

Number

[0355] The absorb short interval algorithm can absorb a short interval sandwiched between two long R-R intervals. For example, one short R-R interval (Xn -1 , Xn +1 ) sandwiched between two long R-R intervals can be absorbed into the second long interval (for example, when Equation 31 is valid, remove Xn and change Xn +1 to (Xn +1 + Xn).

[0356]

Number

[0357] Subsequently, HRV metrics can be calculated from the cleaned R-wave data. For example, the mean R-R interval and SDNN can be calculated 4618. However, for calculating RMSSD, delta R-R cleaning of the cleaned R-wave data may be required to reject outliers based on median / MAD. Further, the cleaned R-wave data can be interpolated for spectral frequency estimation and frequency domain measurements. In various examples, the HRV metrics can be a back-end step (e.g., on a remote device) that may not be performed in real time, and thus, battery can be conserved.

[0358] Furthermore, the HRV algorithm can utilize discontinuous data, including frames of ingestible sensor data and frames of physiological data, in an efficient manner that may not require a large amount of processing power. That is, the HRV algorithm can aggregate and / or stitch together the discontinuous data and output accurate physiological metrics, such as HRV metrics.

[0359] The HRV metrics were measured from eight different patients (e.g., subjects) wearing a wearable device that was torso- and CHRM-mounted for approximately 24 hours under free-living conditions. The wearable device was programmed to acquire an ECG signal every 20 seconds. Accelerometer data was acquired every minute. Impedance measurements were taken every 20 minutes. IEM measurements were disabled during the test. The metric data was extracted from the CHRM using comparison software. The data from the wearable device and CHRM was post-processed in Python and compared according to the data flow shown in FIG. 47.

[0360] Table 28 shows the Spearman correlation coefficients comparing HRV metrics from CHRM data using continuous ECG data with a wearable device using discontinuous ECG data from the wearable device using the algorithms according to the present disclosure without subjecting the discontinuous ECG data to an R-R cleaning algorithm or a delta R-R cleaning algorithm. The R-R cleaning algorithm and / or the delta R-R cleaning algorithm can be sub-components of the HRV algorithm.

[0361] [Table 28]

[0362] As shown, since the Spearman correlation coefficient of the average R-R is high (e.g., close to 1), the average R-R data shows a strong linear correlation between the discontinuous data and the continuous data. Therefore, the average or median heart rate can be accurately determined from the discontinuous data without further HRV cleaning. However, since the Spearman correlation coefficients of SDNN and RMSSD are close to 0, the linear correlation between SDNN and RMSSD between the continuous data and the discontinuous data was insufficient.

[0363] Table 29 shows the Spearman correlation coefficients comparing HRV metrics from CHRM data using continuous ECG data with a wearable device using discontinuous ECG data after subjecting the discontinuous ECG data only to the R-R cleaning algorithm.

[0364] [Table 29]

[0365] As shown, the R-R cleaning algorithm has a minimal impact on the Spearman correlation coefficient of the average R-R. However, the correlation coefficients of SDNN and RMSSD (e.g., close to 1) are significantly improved.

[0366] Table 30 shows the Spearman correlation coefficients comparing HRV metrics from CHRM data using continuous ECG data with a wearable device using discontinuous ECG data subjected only to the delta R-R cleaning algorithm.

[0367]

Table 30

[0368] As shown, the delta R-R cleaning algorithm has the least impact on the Spearman correlation coefficients of mean R-R and SDNN. However, for RMSSD, the Spearman correlation coefficient is significantly improved (e.g., close to 1) compared to no cleaning and, for some patients, compared to R-R cleaning only.

[0369] Table 31 shows the Spearman correlation coefficients comparing HRV metrics from CHRM data using continuous ECG data with a wearable device using discontinuous ECG data subjected to both R-R and delta R-R cleaning algorithms.

[0370]

Table 31

[0371] As shown, using both algorithms (i.e., R-R and delta R-R) has the least impact on the Spearman correlation coefficients of mean R-R and SDNN compared to R-R cleaning only. However, for some patients, the Spearman correlation coefficient of RMSSD was improved (e.g., close to 1) compared to the delta R-R cleaning algorithm only. The delta R-R cleaning algorithm can have a greater impact on RMSSD calculation than R-R cleaning.

[0372] Table 32 shows the Spearman correlation coefficients comparing HRV metrics from CHRM data using continuous ECG data with a wearable device using discontinuous ECG data that has been subjected to an R-R cleaning algorithm and a delta R-R cleaning algorithm, and the data includes gaps (e.g., gaps were added to the data from CHRM and aligned at the same timing as the data from the ECG data from the wearable device according to the present disclosure).

[0373]

Table 32

[0374] Table 33 shows the percent mean absolute error and the percent median absolute error when comparing RMSSD calculated from a wearable device with RMSSD reported from CHRM.

[0375]

Table 33

[0376] Figure 48 shows an example of an HRV metric plot for Patient 5 and shows how well the algorithm according to the present disclosure using discontinuous data matches a comparative algorithm using continuous data.

[0377] Rest

[0378] The processor of the wearable device and / or the remote device can process accelerometer data and ECG data to determine the resting and / or resting heart rate. The resting algorithm can receive accelerometer data and ECG data and can be distributed across the wearable device 102 and the remote device for execution by the control circuit. For example, the resting algorithm can be stored in the memory 112 and utilized by the processor 111 to convert accelerometer data and ECG data into physiological metrics, such as resting metrics. In various examples, the resting algorithm can be stored on the remote device and used in combination with other metrics. For example, the resting algorithm can be used to clean other metric outputs, such as discarding steps detected at rest or determining the resting heart rate from the heart rate metric.

[0379] Based on the acceleration data, it can be determined that the patient is at rest. That is, the patient can be determined to be in a resting state based on the patient's body angle and total activity. For example, if the patient is lying horizontally based on the body angle and is inactive based on the total activity, the patient and the associated physiological data can be classified as a resting state by the resting algorithm. In this way, the resting metric can be used to reduce the power consumption (e.g., measurement frequency) of the wearable device during the resting period and / or selectively use or ignore the data obtained during the resting period.

[0380] Referring to FIG. 49, the rest algorithm can receive accelerometer data. The rest algorithm can determine the patient's body angle based on the accelerometer data and a reference vector 4902. The body angle can be averaged (e.g., boxcar filter) over an average period and average body angle data (ba_avg) can be output 4904. The average period can be a sliding time window, and the window length is parameterized according to the programmable variable body_angle_smoothing_size_mins. The average body window output at step 4904 can be the time stamped at the time in the center of the window.

[0381] Thereafter, the average body angle data can be added to an aggregation window 4906. The rest algorithm can then determine the aggregation period covered by the aggregation window body angle data. The rest algorithm can determine whether it is above an aggregation threshold 4908. The aggregation threshold can be defined according to the programmable parameter aggregation_period_mins. If the aggregation period is less than the aggregation threshold, the rest algorithm can obtain more acceleration data.

[0382] Otherwise, if the aggregation period is above the aggregation threshold, the rest algorithm can calculate the data ratio of the actual number of data points in the aggregation window to the expected number of data points. The rest algorithm compares the data ratio with a programmable data threshold (e.g., data_missing_frac) to determine whether the data in the aggregation window can be reliably used 4910. If the data ratio is less than the data threshold, the rest algorithm can obtain more acceleration data.

[0383] However, when the data ratio is greater than or equal to the data threshold, the resting algorithm can classify the average body angle data within the aggregation window based on the acceleration data. For example, the average body angle data (ba_avg) can be classified as lying horizontally if the average body angle is greater than the first angle threshold (e.g., recumbent_angle_min, -30°) and less than the second angle threshold (e.g., recumbent_angle_max, 30°). Otherwise, the data can be classified as not lying horizontally. Subsequently, the resting algorithm can determine whether the number of average body angle data within the aggregation window classified as lying horizontally is greater than or equal to the recumbent threshold 4912. The recumbent threshold can be a programmable parameter ("minimum_recumbent_frac"). If the number of average body angle data within the aggregation window classified as lying horizontally is less than the recumbent threshold, it can be determined that the data within the aggregation window does not correspond to the patient's lying position 4914. Otherwise, the resting algorithm can proceed to step 4926.

[0384] In addition to the body angle, the resting algorithm can account for the total activity of the accelerometer data. That is, the resting algorithm can calculate the total activity from the accelerometer data 4916. The resting algorithm can calculate the intermittent inactivity data from the total activity data 4918. That is, as shown in FIG. 50, the resting algorithm calculates the standard deviation over the SD period 5002. The SD period can be a sliding time window, and the window length is parameterized according to the programmable variable acc_std_win_size_mins. The standard deviation of each axis of the total activity data can be taken individually, and the standard deviations of each axis can be summed.

[0385] The quiet-time algorithm 5004 can remove values above the SD threshold from the summed standard deviation data. The SD threshold can be parameterized according to the programmable parameter std_thresh. By removing values above the SD threshold, the influence of accidental shifts (e.g., rotations) in the orientation by the patient during quiet periods that can cause spikes in the standard deviation can be limited. The removed values can be replaced with the immediately preceding measured values.

[0386] Thereafter, the standard deviation data can be averaged over an aggregation period 5006. The aggregation period can be parameterized according to the programmable parameter activity_smoothing_size_mins. The standard deviation data can be added to an aggregation window 5008.

[0387] Returning to FIG. 49, after adding the standard deviation data to the aggregation window, the quiet-time algorithm 4920 can determine the aggregation period covered by the standard deviation data within the aggregation window if the aggregation period is above an aggregation threshold. If the aggregation period is below the aggregation threshold, the quiet-time algorithm can obtain more acceleration data.

[0388] Otherwise, if the aggregation period is above the aggregation threshold, the quiet-time algorithm can calculate the data ratio of the actual number of data points within the aggregation window to the expected number of data points. The quiet-time algorithm compares the data ratio with a programmable data threshold to determine whether the data within the aggregation window can be reliably used 4922. If the data ratio is below the data threshold, the quiet-time algorithm can obtain more acceleration data.

[0389] However, when the data ratio is greater than or equal to the data threshold, the rest algorithm can classify the standard deviation data within the aggregation window. For example, the standard deviation data can be classified as inactive when the average body angle is less than or equal to the SD threshold (e.g., smoothed_acc_std_max, 0.065). Otherwise, the standard deviation data can be classified as active. Thereafter, the rest algorithm determines 4924 whether the number of standard deviation data within the aggregation window classified as inactive is greater than or equal to the inactive threshold. The inactive threshold can be a programmable parameter ("minimum_inactive_frac"). If the number of standard deviation data within the aggregation window classified as inactive is less than the inactive threshold, the data within the aggregation window can be determined to be active 4914. If the number of standard deviation data within the aggregation window classified as inactive is greater than or equal to the inactive threshold, the data within the aggregation window can be determined to be inactive, and the rest algorithm can proceed to step 4926.

[0390] After lying down and classifying the acceleration data as inactive, the acceleration data can be further classified as rest data 4926. The rest data classification can be stored in memory 4928. In this way, the rest algorithm can utilize discontinuous data including ingestible sensor data and physiological data.

[0391] The rest algorithm can have programmable parameters as shown in Table 34.

[0392]

Table 34

[0393] A wearable device can determine whether accelerometer data should be classified as resting data at regular intervals, such as every 10 minutes. Resting data can be further defined as sleep. In various examples, primary rest can be calculated as the largest block of data classified as resting data during a 24-hour period (e.g., between 3:00 PM and 3:00 PM). Non-adjacent rest segments can be added on either side of the primary rest if they are separated by less than a non-rest separation threshold (e.g., 30 minutes) and are not larger than the new rest block with the added gap.

[0394] The resting heart rate can be a heart rate metric calculated during a period of minimal body activity, such as sleep. That is, the resting heart rate can be calculated from ECG data corresponding to accelerometer data classified as resting data (e.g., based on a time stamp). In various examples, the ECG data can be classified as resting data based on the associated accelerometer data (e.g., based on a time stamp).

[0395] The resting heart rate can be calculated from a sliding window of the median of the resting heart rate metric values. The resting heart rate can be defined as the lowest local median. Other parameters that can be used to define the resting heart rate include the time to define a new period (e.g., a 24-hour period); the length of the window to average the heart rate metric values over the rest period; the time (in minutes) to slide the window for the next calculation; and the minimum heart rate value for considering the window valid.

[0396] Furthermore, since the heart rate value and the resting value may not be equal, the resting value can be stored in a separate queue from the heart rate metric value.

[0397] U.S. Provisional Patent Application No. 62 / 685,855, filed on June 15, 2018, entitled "Monitoring of Sensor Assemblies for Replacement Strips"; U.S. PCT Application ___, filed concurrently therewith, Attorney Docket No. PRTS-220WO, entitled "Monitoring of Sensor Assemblies for Replacement Strips"; U.S. Provisional Patent Application No. 62 / 685,784, filed on June 15, 2018, entitled "Re-Wearable Physiological Monitoring Devices"; and U.S. PCT Application ___, filed concurrently therewith, Attorney Docket No. PRTS-228WO, entitled "Re-Wearable Physiological Monitoring Devices" are hereby incorporated by reference in their entireties.

[0398] Although several forms have been illustrated and described, it is not the applicant's intention to limit or restrict the appended claims in such detail. Many modifications, variations, changes, substitutions, combinations, and equivalents can be made to these forms, and those skilled in the art will be able to conceive of them without departing from the scope of the present disclosure. Further, the structure of each element related to the described forms can be alternatively described as means for providing the function that the element performs. Also, if a material is disclosed for a particular component, other materials may be used. Accordingly, it should be understood that the foregoing description and the appended claims are intended to cover all such modifications, combinations, and variations that are included within the scope of the disclosed forms. The appended claims are intended to cover all such modifications, variations, changes, substitutions, modifications, and equivalents.

[0399] The foregoing detailed description has described various forms of devices and / or processes by use of block diagrams, flowcharts, and / or examples. To the extent such block diagrams, flowcharts, and / or examples include functions and / or operations, it will be understood by those skilled in the art that each function and / or operation within the scope of such block diagrams, flowcharts, and / or examples can be implemented individually and / or collectively by a wide variety of hardware, software, firmware, or substantially any combination thereof. Those skilled in the art will understand that some examples of the forms disclosed herein can be equivalently implemented, in whole or in part, as a computer program executed by a computer, as a program executed by a processor (e.g., as a program executed by a microprocessor), as firmware, or as substantially any combination thereof, in an integrated circuit, and that designing electrical circuits and / or writing code for software and / or firmware is well within the skill of those skilled in the art in view of the present disclosure. Additionally, those skilled in the art will understand that the mechanisms of the subject matter described herein can be distributed in a variety of forms of program products, and that the subject matter described herein applies regardless of the particular type of signal transmission medium used to actually effect the distribution.

[0400] The instructions used to program the logic for executing the various disclosed embodiments can be stored in memory within a system such as dynamic random access memory (DRAM), cache, flash memory, or other storage. Further, the instructions can be distributed via a network or by other computer-readable media. Accordingly, a machine-readable medium can include, but is not limited to, any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer), such as a floppy disk, optical disk, compact disc read-only memory (CD-ROM), magneto-optical disk, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic or optical card, flash memory, or any tangible machine-readable storage used in the transmission of information via the Internet via electrical, optical, acoustic, or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.). Accordingly, a non-transitory computer-readable medium includes any type of tangible machine-readable medium suitable for storing or transmitting electronic instructions or information in a form readable by a machine (e.g., a computer).

[0401] As used herein, the term "control circuit" may refer to, for example, a wiring circuit, a programmable electrical circuit (e.g., a computer processor including one or more individual instruction processing cores, processing units, processors, microcontrollers, microcontroller units, controllers, digital signal processors (DSPs), programmable logic devices (PLDs), programmable logic arrays (PLAs), or FPGAs), a state machine electrical circuit, firmware that stores instructions executable by a programmable electrical circuit, and any combination thereof. The control circuit may be embodied, collectively or individually, as an electrical circuit that forms part of a larger system, such as, for example, an IC, an ASIC, an SoC, a desktop computer, a laptop computer, a tablet computer, a server, a smartphone, etc. Thus, as used herein, "control circuit" includes, but is not limited to, at least one individual electrical circuit, an electrical circuit having at least one IC, an electrical circuit having at least one application specific IC, an electrical circuit forming a general purpose computing device configured by a computer program (e.g., a general purpose computer configured by a computer program that at least partially executes the processes and / or devices described herein or a microprocessor configured by a computer program that at least partially executes the processes and / or devices described herein), an electrical circuit forming a memory device (e.g., in the form of RAM), and / or an electrical circuit forming a communication device (e.g., a modem, a communication switch, or an optoelectronic device). Those skilled in the art will understand that the subject matter described herein may be implemented in an analog or digital manner or some combination thereof.

[0402] As used herein, the term "logic" may refer to an app, software, firmware, and / or circuitry configured to perform any of the foregoing operations. The software can be embodied as a software package, code, instructions, instruction sets, and / or data recorded in a non-transitory computer-readable storage medium. The firmware can be embodied as code, instructions, or instruction sets, and / or data hard-coded (e.g., non-volatile) in a memory device.

[0403] As used herein, terms such as "component", "system", "module", etc. can refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution.

[0404] As used herein, the term "algorithm" refers to a consistent series of steps that produce a desired result, where a "step" refers to an operation of a physical quantity and / or a logical state that can take the form of an electrical or magnetic signal and that can be stored, transferred, combined, compared, and otherwise manipulated, although not necessarily so. It is common usage to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc. These and similar terms may be associated with appropriate physical quantities and are merely convenient labels applied to these quantities and / or states.

[0405] The network may include a packet-switching network. The communication devices may be capable of communicating with each other using a selected packet-switching network communication protocol. An example of a communication protocol may include an Ethernet communication protocol that enables communication using the Transmission Control Protocol / Internet Protocol (TCP / IP). The Ethernet protocol may conform to or be compatible with the Ethernet standard titled "IEEE 802.3 Standard", December 2008 edition and / or later editions of this standard, published by the Institute of Electrical and Electronics Engineers (IEEE). Alternatively or additionally, the communication devices may be capable of communicating with each other using the X.25 communication protocol. The X.25 communication protocol may conform to or be compatible with the standards promulgated by the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T). Alternatively or additionally, the communication devices may be capable of communicating with each other using the Frame Relay communication protocol. The Frame Relay communication protocol may conform to or be compatible with the standards published by the International Telegraph and Telephone Consultative Committee (CCITT) and / or the American National Standards Institute (ANSI). Alternatively or additionally, the transceivers may be capable of communicating with each other using the Asynchronous Transfer Mode (ATM) communication protocol. The ATM communication protocol may conform to or be compatible with the ATM standards published by the ATM Forum, the August 2001 edition titled "ATM-MPLS Network Interworking 2.0" and / or later editions of this standard. Of course, different and / or post-deployment connection type network communication protocols are equally contemplated herein.

[0406] As is apparent from the foregoing disclosure, unless otherwise specified, throughout the foregoing disclosure, discussions using terms such as "processing", "computing", "calculating", "determining", "displaying", etc. refer to the operation and processes of a computer system or similar electronic computing device that manipulates data represented as physical (electronic) quantities within the registers and memories of the computer system and converts it into other data similarly represented as physical quantities within the computer system memory or registers or other such information storage, transmission, or display devices.

[0407] Components may be referred to herein as "configured to", "configurable to", "operable / operationally to", "adapted / adaptable to", "capable of", "conformable / conformed to", etc. One of ordinary skill in the art will recognize that "configured to" generally encompasses, unless otherwise required by context, components in an active state, components in a non-active state, and / or components in a standby state.

[0408] Those skilled in the art will generally understand that the terms used herein, particularly in the appended claims (e.g., the characterizing part of the appended claims), are intended to be "open" terms (e.g., the term "including" should be construed as "including but not limited to", the term "comprising" should be construed as "at least comprising", the term "includes" should be construed as "including but not limited to"). It will further be understood by those skilled in the art that where a specific number of introduced claim recitations is intended, such intent is explicitly recited in the claim, and where no such recitation is present, no such intent exists. For example, for purposes of illustration, the following appended claims may include the use of introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to limit any particular claim that introduces a claim recitation by use of the indefinite article "a" or "an" to a claim that includes only one such recitation, even where the same claim includes both an introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should typically be construed as meaning "at least one" or "one or more"); the same applies to the use of definite articles used to introduce claim recitations.

[0409] In addition, even when the description of a specific number of introduced claims is explicitly stated, one of ordinary skill in the art will understand that such a description should typically be construed to mean at least the number stated (e.g., a minimal description of "two descriptions" without other qualifying language typically means at least two descriptions, or two or more descriptions). Further, in examples where conventions similar to "at least one of A, B, and C" are used, generally such a construction is intended in the sense that one of ordinary skill in the art will understand the convention (e.g., "a system having at least one of A, B, and C" includes, without limitation, a system having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together). It will further be understood by one of ordinary skill in the art that in any of the specification, claims, or drawings, a phrase presenting adjacent words and / or two or more other words will typically be understood to contemplate the possibility of including one, any, or both of the plurality of terms, unless the context indicates otherwise. For example, the phrase "A or B" will typically be understood to include the possibilities of "A," "B," or "A and B."

[0410] Regarding the appended claims, one of ordinary skill in the art will understand that the operations described therein can generally be performed in any order. Also, although various operation flow diagrams are presented in sequence, it should be understood that the various operations may be performed in an order different from that shown, or simultaneously. Examples of such orders may include, unless the context indicates otherwise, repetitive, alternating, interrupted, permuted, incremental, preparatory, capture, simultaneous, reverse, or other modified orders. Further, words such as "responsive to," "associated with," or other past participle adjectives generally do not intend to exclude such modifications, unless the context indicates otherwise.

[0411] Any patent application, patent, non-patent application, or other disclosure sample referred to in this specification is incorporated herein by reference to the extent that the incorporated sample does not conflict with this specification. Accordingly, to the extent necessary, the disclosure explicitly described in this specification prevails over incorporated materials that conflict therewith and is incorporated herein by reference. Any material, or portion thereof, that is purported to be incorporated herein by reference but conflicts with an existing definition, description, or other disclosure material described herein is incorporated only to the extent that no conflict arises between the incorporated material and the existing disclosure material.

[0412] In summary, many advantages resulting from adopting the concepts described herein are described. The foregoing description is presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise examples disclosed. Modifications or variations are possible in light of the above teachings. The examples were chosen and described in order to explain the principles and the practical application thereof, with various modifications that are suited to the particular use contemplated, thereby enabling one of ordinary skill in the art to utilize the various examples. The claims presented herein are intended to define the full scope. The following items are elements described in the claims at the time of international filing. (Item 1) A system for measuring a patient's step count, A wearable device comprising an accelerometer, configured to be coupled to the patient's body and configured to detect discontinuous data using at least the accelerometer, the discontinuous data including a frame of ingestible sensor data and a frame of the patient's physiological data scattered in a time gap between the frames of the ingestible sensor data, the wearable device; At least one processor of the wearable device and a remote device communicably connected to the wearable device, configured to measure the step count in a speed range of 80 to 150 steps per minute using the detected physiological data with an average error measured over at least 1000 steps being ±3%; A system comprising the same. (Item 2) The system according to item 1, wherein the physiological data includes accelerometer data from the accelerometer. (Item 3) The processor is configured to enhance the accelerometer data, calculate the number of level crossings of the enhanced accelerometer data, thereby generating the step count, and is further configured as in the system according to item 2. (Item 4) The system according to item 3, wherein the processor is configured to enhance the accelerometer data in response to a measurement that the total activity of the accelerometer data is below a first threshold and above a second threshold. (Item 5) The processor configured to enhance the accelerometer data is configured to process the accelerometer data through at least one of a boxcar filter, an absolute value filter, a low-pass filter, a high-pass filter, and an average adjustment, and comprises the processor as described above, and is a system according to any one of items 3 to 4. (Item 6) The system according to any one of items 2 to 5, wherein the processor is further configured to process boundary effects within the frame of the accelerometer data. (Item 7) The system according to any one of items 1 to 6, further comprising the remote device, wherein the remote device is configured to receive discontinuous data from the wearable device. (Item 8) The system according to any one of items 1 to 7, wherein the ingestible sensor data is generated by an ingestible event marker after contact with the patient's body fluid. (Item 9) The system according to any one of items 1 to 8, wherein the wearable device is configured to be removably attached to the patient's skin. (Item 10) A wearable device comprising a processor coupled to a non-transitory memory, wherein when executed by the processor, the non-transitory memory causes the processor to receive discontinuous data including a frame of ingestible sensor data and a frame of the patient's physiological data scattered within a time gap between the frames of the ingestible sensor data, and measure a step count in a speed range of 80 to 150 steps per minute using the detected physiological data having an average error of ±3% measured over at least 1000 steps. A wearable device including machine-executable instructions. (Item 11) The wearable device according to item 10, wherein the physiological data includes accelerometer data from the accelerometer. (Item 12) The machine-executable instructions when executed by the processor, further cause the processor to enhance the accelerometer data and calculate the number of level crossings of the enhanced accelerometer data, thereby generating the step count. The wearable device according to item 11. (Item 13) The machine-executable instructions, when executed by the processor, cause the processor to enhance the accelerometer data in response to a measurement that the total activity of the accelerometer data is less than or equal to a first threshold and greater than or equal to a second threshold, for the wearable device of item 12. (Item 14) The machine-executable instructions that cause the processor to enhance the accelerometer data when executed by the processor, when executed by the processor, further cause the processor to boxcar filter, absolute value filter, low-pass filter, high-pass filter, and mean adjustment, The wearable device of item 12 or 13, including machine-executable instructions that cause the accelerometer data to be processed through at least one of them. (Item 15) The machine-executable instructions, when executed by the processor, cause the processor to further process boundary effects within the frame of the acceleration data, for the wearable device of any one of items 11 - 14. (Item 16) The ingestible sensor data is generated by an ingestible event marker after contact with the patient's body fluid, for the wearable device of any one of items 10 - 15. (Item 17) The wearable device is configured to be removably attached to the patient's skin, for the wearable device of any one of items 10 - 16. (Item 18) A method for measuring a patient's step count from discontinuous data, comprising Receiving discontinuous data including a frame of ingestible sensor data and a frame of physiological data scattered at a time gap between the frames of the ingestible sensor data, wherein the physiological data includes accelerometer data from an accelerometer; Enhancing the accelerometer data; Calculating the number of level crossings in the enhanced accelerometer data, thereby generating the step count; A method comprising the above. (Item 19) The method according to item 18, wherein calculating the step count is performed in a speed range of 80 to 150 steps per minute using the detected physiological data with an average error measured over at least 1000 steps being ±3%. (Item 20) The method according to any one of items 18 or 19, wherein enhancing the accelerometer data is in response to a measurement where the total activity of the accelerometer data is below a first threshold and above a second threshold. (Item 21) Enhancing the accelerometer data comprises Processing the accelerometer data through at least one of a boxcar filter, an absolute value filter, a low-pass filter, a high-pass filter, and an average adjustment. The method according to any one of items 18 to 20. (Item 22) The method according to any one of items 18 to 21, further comprising processing boundary effects within the frame of the acceleration data. (Item 23) The method according to any one of items 18 to 22, further comprising generating the ingestible sensor data by contacting an ingestible event marker with the patient's body fluid. (Item 24) Further comprising removably attaching a wearable device to the skin of the patient, wherein receiving the discontinuous data includes receiving the discontinuous data by the wearable device, the method according to any one of items 18 to 23. (Item 25) A system for automatically measuring orientation, A wearable device comprising an accelerometer, configured to be coupled to the body of the patient and configured to detect discontinuous data using at least the accelerometer, the discontinuous data including a frame of ingestible sensor data and a frame of the patient's physiological data scattered in a time gap between the frames of the ingestible sensor data, a wearable device; At least one processor of the wearable device and a remote device communicably connected to the wearable device, configured to automatically measure the orientation of the wearable device with respect to the body of the patient using the detected physiological data, a processor; A system comprising. (Item 26) The system according to item 25, wherein the physiological data includes accelerometer data from the accelerometer. (Item 27) The system according to item 26, wherein the processor is further configured to measure the orientation of the patient based on the accelerometer data. (Item 28) The processor is configured to automatically measure the orientation of the wearable device, Measure a reference vector, the measurement being Determining that the patient is taking steps based on the accelerometer data, In response to the determination that the patient is taking steps, taking the accelerometer record including the accelerometer data and binning it independently for at least two axes based on the acceleration data, Calculate a reference vector based on each bin of the at least two axes having the largest accelerometer records, Calculate the orientation of the patient's body based on the reference vector and the accelerometer data, The system according to any one of items 26 or 27, further comprising the processor configured to include the processor configured as described above. (Item 29) The system according to item 28, wherein the processor is configured to independently capture accelerometer records in the bins for three axes. (Item 30) Capture a new accelerometer record in the bin, The system according to item 28 or 29, further comprising the processor configured to recalculate the reference vector based on the new accelerometer record. (Item 31) The system according to item 30, further comprising the processor configured to freeze further updates of the reference vector after some accelerometer records in the bin reach or exceed a bin count threshold. (Item 32) The system according to any one of items 28 to 31, wherein the orientation of the body is a normalized convex part of the average acceleration vector on the reference vector. (Item 33) The system according to any one of items 28 to 32, wherein the accelerometer record further includes at least one of step count, body angle, total activity, level crossing, average acceleration, reference vector, energy consumption, signal enhancement flag, and standard deviation of the acceleration data. (Item 34) The system according to any one of items 25 to 33, wherein the wearable device is configured to be removably attached to the patient's skin. (Item 35) The ingestible sensor data is the system according to any one of items 25 to 34, generated by an ingestible event marker after contact with the patient's body fluid. (Item 36) A wearable device comprising a processor coupled to a non-transitory memory, wherein when executed by the processor, the non-transitory memory causes the processor to receive discontinuous data including a frame of ingestible sensor data and a frame of physiological data scattered in a time gap between the frames of the ingestible sensor data, the physiological data including accelerometer data, automatically measure the orientation of the wearable device with respect to the patient's body using the accelerometer data. A wearable device including machine-executable instructions. (Item 37) The machine-executable instructions, when executed by the processor, cause the processor to measure the orientation of the patient based on the accelerometer data, the wearable device according to item 36. (Item 38) The machine-executable instructions, when executed by the processor, cause the processor to measure a reference vector, the measurement determines that the patient is taking a step based on the accelerometer data, in response to the determination that the patient is taking a step, takes the accelerometer records including the accelerometer data into bins independently for at least two axes based on the acceleration data, calculates a reference vector based on each bin of the at least two axes having the maximum accelerometer record, including calculating the orientation of the patient's body based on the reference vector and the accelerometer data, the wearable device according to item 36 or 37. (Item 39) The instructions executable on the machine, when executed by the processor, cause the processor to capture accelerometer recordings into the bin independently for three axes, for the wearable device according to item 38. (Item 40) The instructions executable on the machine, when executed by the processor, cause the processor to capture new accelerometer recordings into the bin, recalculate the reference vector based on the new accelerometer recordings, for the wearable device according to item 38 or 39. (Item 41) The instructions executable on the machine, when executed by the processor, cause the processor to freeze further updates of the reference vector after some accelerometer recordings in the bin reach a bin count threshold, for the wearable device according to item 40. (Item 42) The orientation of the body is the normalized convex part of the average acceleration vector on the reference vector, for the wearable device according to any one of items 38 to 41. (Item 43) The accelerometer recordings further include at least one of step count, body angle, total activity, level crossing, average acceleration, reference vector, energy consumption, signal enhancement flag, and standard deviation of the acceleration data, for the wearable device according to any one of items 38 to 42. (Item 44) The ingestible sensor data is generated by an ingestible event marker after contact with the patient's body fluid, for the wearable device according to any one of items 36 to 43. (Item 45) A method for automatically measuring orientation, comprising Receiving discontinuous data including a frame of ingestible sensor data and a frame of physiological data scattered at a time gap between the frames of the ingestible sensor data, wherein the physiological data includes accelerometer data from a wearable device, automatically measuring the orientation of the wearable device with respect to the patient's body using the accelerometer data, A method comprising: (Item 46) The method according to item 45, further comprising measuring the orientation of the patient based on the accelerometer data. (Item 47) Measuring a reference vector, the measurement comprising: determining that the patient is taking a step based on the accelerometer data; in response to the determination that the patient is taking a step, binning the accelerometer records including the accelerometer data independently for at least two axes based on the acceleration data; calculating the reference vector based on each bin of the at least two axes having the maximum accelerometer record; A measurement comprising: calculating the orientation of the patient's body based on the reference vector and the accelerometer data, The method according to item 45 or 46, further comprising: (Item 48) The method according to item 47, further comprising binning the accelerometer records independently for three axes into the bins. (Item 49) binning new accelerometer records into the bins; recalculating the reference vector based on the new accelerometer records; The method according to item 47 or 48, further comprising: (Item 50) The method according to item 49, further comprising freezing further updates of the reference vector after some of the accelerometer recordings in the bin reach or exceed the bin count threshold. (Item 51) The method according to any one of items 47 to 50, wherein the orientation of the body is a normalized convex portion of the average acceleration vector on the reference vector. (Item 52) The method according to any one of items 47 to 51, wherein the accelerometer recordings further include at least one of step count, body angle, total activity, level crossing, average acceleration, reference vector, energy consumption, signal enhancement flag, and standard deviation of the acceleration data. (Item 53) The method according to any one of items 45 to 52, wherein ingestible sensor data is generated by an ingestible event marker after contact with the patient's body fluid. (Item 54) The method according to any one of items 45 to 53, further comprising removably attaching a wearable device to the patient's skin, and receiving the discontinuous data includes receiving the discontinuous data by the wearable device. (Item 55) A system for measuring a patient's heart rate, comprising A wearable device having electrodes, configured to be coupled to the patient's body and configured to detect discontinuous data using at least the electrodes, the discontinuous data including a frame of ingestible sensor data and a frame of the patient's physiological data scattered in a time gap between the frame of the ingestible sensor data, and At least one vector coprocessor of the wearable device and a remote device communicably connected to the wearable device, the vector coprocessor being configured to enhance the frame of the physiological data. At least one processor of the wearable device and the remote device, the processor being configured to measure the heart rate of the patient using the enhanced frame of the physiological data; A system comprising. (Item 56) The vector coprocessor configured to enhance the frame of the physiological data, High-pass filter, Low-pass filter, Downsampling filter, Derivative filter, Correction filter, and Boxcar averaging filter, The system according to item 55, comprising the vector coprocessor configured to process the physiological data through at least one of. (Item 57) The processor configured to process the physiological data, Peak finder, Adaptive threshold, Peak purification, Spurious peak removal, and Amplitude fluctuation removal, The system according to item 55 or 56, configured to measure the heart rate by at least one technique selected from the group consisting of. (Item 58) The system according to item 57, wherein the processor comprises the processor configured to detect a rising edge and a falling edge based on the physiological data crossing a first threshold, and configured to process the physiological data using the peak finder. (Item 59) The processor, Detects a first number of peaks in the physiological data based on the first threshold, Detects a second number of peaks in the physiological data based on a second threshold different from the first threshold, The processor is configured to adjust the first threshold value and the second threshold value until the number of the first peaks becomes equal to the number of the second peaks, or until a threshold value of the number of adjustment repetitions is reached or exceeded, and the system according to item 58, which is configured to process the physiological data having the adaptive threshold value and includes the processor. (Item 60) The system according to any one of items 57 to 59, wherein the processor is configured to process the physiological data by spur peak removal, including being configured to remove peaks of the physiological data that are closer to each other than a distance threshold value. (Item 61) The system according to any one of items 57 to 60, wherein the processor is configured to process the physiological data by amplitude fluctuation removal, including calculating an interval between peaks in the physiological data and merging two peaks in a frame of the physiological data into one peak, or splitting a peak into two peaks in the physiological data based on the calculated interval. (Item 62) The system according to any one of items 57 to 61, wherein the processor is configured to ignore a frame of physiological data including invalid data while measuring the heart rate. (Item 63) The processor further is configured to measure at least one quality metric selected from the group consisting of peak spread, median absolute deviation, and quality score of each frame of physiological data, and the processor is configured to ignore a frame of the physiological data based on a comparison between the at least one quality metric and a quality threshold value. The system according to item 62. (Item 64) The system according to any one of items 55 to 63, wherein the vector coprocessor is a vector operation coprocessor on an application-specific integrated circuit (ASIC). (Item 65) The system according to any one of items 55 to 64, wherein the processor is an advanced reduced instruction set computer processor on the ASIC. (Item 66) The system according to any one of items 55 to 64, wherein the wearable device includes an electrocardiogram (ECG) circuit operably connected to the electrodes. (Item 67) The system according to item 66, wherein the physiological data includes ECG data from the ECG circuit. (Item 68) The system according to any one of items 55 to 67, wherein the wearable device is configured to be removably attached to the skin of the patient. (Item 69) The system according to any one of items 55 to 68, wherein the ingestible sensor data is generated by an ingestible event marker after contact with the body fluid of the patient. (Item 70) A wearable device including a processor coupled to a non-transitory memory, wherein when the non-transitory memory is executed by the processor and / or a vector coprocessor, the processor and / or the coprocessor is caused to receive discontinuous data including a frame of ingestible sensor data and a frame of the physiological data of the patient scattered in a time gap between the frames of the ingestible sensor data, enhance the frame of the physiological data by the coprocessor, measure the heart rate of the patient using the enhanced frame of the physiological data by the processor. A wearable device including machine-executable instructions. (Item 71) The machine-executable instructions, when executed by the vector coprocessor, cause the vector coprocessor to a high-pass filter, a low-pass filter, a downsampling filter Derivative filter, correction filter, and boxcar averaging filter, The wearable device according to item 70, wherein the physiological data is processed through at least one of them. (Item 72) When the machine-executable instructions are executed by the processor, the processor is caused to peak finder, adaptive threshold, peak purification, spurious peak removal, and amplitude fluctuation removal, The wearable device according to item 70 or 71, wherein the physiological data is processed by at least one technique selected from the group consisting of. (Item 73) When the machine-executable instructions are executed by the processor, the processor is caused to use the peak finder to process the physiological data so as to detect rising edges and falling edges based on the physiological data crossing a first threshold. The wearable device according to item 72. (Item 74) When the machine-executable instructions are executed by the processor, the processor is caused to detect a first number of peaks in the physiological data based on the first threshold, detect a second number of peaks in the physiological data based on a second threshold different from the first threshold, adjust the first threshold and the second threshold until the first number of peaks is equal to the second number of peaks, or until a threshold number of adjustment iterations is reached or exceeded. The wearable device according to item 72 or 73. (Item 75) The machine-executable instructions, when executed by the processor, cause the processor to process the physiological data in the spurious peak removal, including the processor configured to remove peaks of the physiological data that are closer to each other than a distance threshold, according to any one of items 72 to 74 of the wearable device. (Item 76) The machine-executable instructions, when executed by the processor, cause the processor to process the physiological data with the amplitude fluctuation removal, calculate the interval between peaks in the physiological data, and based on the calculated interval, merge two peaks into one peak within a frame of the physiological data or split a peak into two peaks in the physiological data, according to any one of items 72 to 75 of the wearable device. (Item 77) The machine-executable instructions, when executed by the processor, cause the processor to ignore a frame of physiological data containing invalid data while measuring the heart rate, according to any one of items 72 to 75 of the wearable device. (Item 78) The machine-executable instructions, when executed by the processor, cause the processor to measure at least one quality metric selected from the group consisting of peak spread, median absolute deviation, and quality score of each frame of physiological data, and the processor is configured to ignore the frame of physiological data based on a comparison between the at least one quality metric and a quality threshold. The wearable device of item 77. (Item 79) The physiological data includes electrocardiogram (ECG) data from an ECG circuit, according to any one of items 70 to 78 of the wearable device. (Item 80) The wearable device is configured to be removably attached to the skin of the patient, according to any one of items 70 to 79 of the wearable device. (Item 81) The ingestible sensor data is the wearable device according to any one of items 70 to 80, generated by an ingestible event marker after contact with the patient's body fluid. (Item 82) A method for measuring a heart rate, receiving discontinuous data using at least the electrodes, the discontinuous data including a frame of ingestible sensor data and a frame of the patient's physiological data scattered in a time gap between the frames of the ingestible sensor data, enhancing the frame of the physiological data by a coprocessor, measuring the heart rate of the patient using the enhanced frame of the physiological data by a processor. (Item 83) Enhancing the frame of the physiological data includes a high-pass filter, a low-pass filter, a downsampling filter, a derivative filter, a correction filter, and a boxcar averaging filter, processing the physiological data through at least one of them, the method according to item 82. (Item 84) Measuring the heart rate of the patient includes a peak finder, an adaptive threshold, peak purification, spurious peak removal, and amplitude fluctuation removal, processing the physiological data by at least one technique selected from the group consisting of, the method according to item 82 or 83. (Item 85) Measuring the heart rate includes processing the physiological data via the peak finder to detect a rising edge and a falling edge based on the physiological data crossing a first threshold, the method according to item 84. (Item 86) Detecting a first number of peaks in the physiological data based on the first threshold; Detecting a second number of peaks in the physiological data based on a second threshold different from the first threshold; Adjusting the first threshold and the second threshold until the first number of peaks equals the second number of peaks, or until a threshold number of adjustment iterations is reached or exceeded; The method according to item 85, further comprising the above. (Item 87) Measuring the heart rate includes processing the physiological data via the spurious peak removal, which includes removing peaks within the physiological data that are closer to each other than a distance threshold, the method according to item 85 or 86. (Item 88) Measuring the heart rate includes processing the physiological data using the amplitude fluctuation removal, which includes calculating the intervals between peaks in the physiological data and merging two peaks into one peak or splitting a peak into two peaks within the frame of the physiological data based on the calculated intervals, the method according to any one of items 85 - 87. (Item 89) The method according to any one of items 82 - 88, further comprising ignoring frames of physiological data that include invalid data during measuring the heart rate. (Item 90) Measuring at least one quality metric selected from the group consisting of peak spread, median absolute deviation, and quality score of each frame of physiological data; The method according to item 89, further comprising comparing the quality metric with a quality threshold, and ignoring the frame of the physiological data based on the comparison. (Item 91) The method according to any one of Items 82 to 90, wherein the physiological data includes electrocardiogram (ECG) data from an ECG circuit. (Item 92) The method according to any one of Items 82 to 91, wherein the ingestible sensor data is generated by an ingestible event marker after contact with the body fluid of the patient. (Item 93) The method according to any one of Items 82 to 92, further comprising removably attaching a wearable device to the skin of the patient, and receiving the discontinuous data includes receiving the discontinuous data by the wearable device. (Item 94) A system for measuring level crossings in discontinuous data, A wearable device configured to be coupled to a patient's body and configured to detect discontinuous data, the discontinuous data including a frame of ingestible sensor data and a frame of physiological data from the patient interspersed in a time gap between the frames of the ingestible sensor data, and a wearable device, At least one processor of the wearable device and a remote device communicatively connected to the wearable device, the processor being configured to process boundary effects in the frame of the physiological data and calculate the number of level crossings. A system comprising. (Item 95) The system according to Item 94, wherein the physiological data includes at least one of accelerometer data from an accelerometer and electrocardiogram (ECG) data from an ECG circuit. (Item 96) The system according to Item 94 or 95, wherein the processor is configured to measure the direction of each level crossing. (Item 97) The processor is configured to increase the number of level crossings in response to a determination that a level crossing at the end of a first frame of physiological data is in the same direction as a level crossing at the start of a second frame of physiological data, the first and second frames being sequentially arranged within the physiological data, the system according to any one of items 94 to 96. (Item 98) The processor is configured to detect a change in the slope of a frame of the physiological data and increase the number of level crossings in response to the change in slope, the system according to any one of items 94 to 97. (Item 99) The change in slope is before a level crossing at the start of a frame of physiological data, the system according to item 98. (Item 100) The change in slope is after a level crossing at the end of a frame of the physiological data, the system according to item 98 or 99. (Item 101) The wearable device is configured to be removably attached to the skin of the patient, the system according to any one of items 94 to 100. (Item 102) The ingestible sensor data is generated by an ingestible event marker after contact with the patient's body fluid, the system according to any one of items 94 to 101. (Item 103) A wearable device comprising a processor coupled to a non-transitory memory, the non-transitory memory, when executed by the processor, causing the processor to receive discontinuous data including a frame of ingestible sensor data and a frame of physiological data from the patient scattered in the time gap between the frames of the ingestible sensor data, process a boundary effect in the frame of the physiological data to calculate the number of level crossings in the physiological data, A wearable device including machine-executable instructions. (Item 104) The wearable device according to item 103, wherein the physiological data includes at least one of accelerometer data from an accelerometer and electrocardiogram (ECG) data from an ECG circuit. (Item 105) The wearable device according to item 103 or 104, wherein the machine-executable instructions, when executed by the processor, cause the processor to measure the direction of each level crossing. (Item 106) The wearable device according to any one of items 103 to 105, wherein the machine-executable instructions, when executed by the processor, cause the processor to increase the number of level crossings in response to a determination that a level crossing at the end of a first frame of physiological data is in the same direction as a level crossing at the start of a second frame of physiological data, and the first and second frames are sequentially arranged within the physiological data. (Item 107) The wearable device according to any one of items 103 to 106, wherein the machine-executable instructions, when executed by the processor, cause the processor to detect a change in the slope of a frame of the physiological data and increase the number of level crossings in response to the change in slope. (Item 108) The wearable device according to item 107, wherein the change in slope is before a level crossing at the start of a frame of physiological data. (Item 109) The wearable device according to item 107 or 108, wherein the change in slope is after a level crossing at the end of a frame of the physiological data. (Item 110) The wearable device according to any one of items 103 to 109, wherein the ingestible sensor data is generated by an ingestible event marker after contact with the patient's body fluid. (Item 111) A method for measuring the number of level crossings in discontinuous data, receiving discontinuous data including a frame of ingestible sensor data and a frame of physiological data from the patient scattered in a time gap between the frames of the ingestible sensor data; processing boundary effects in the frame of the physiological data and calculating the number of level crossings in the discontinuous data; A method comprising: (Item 112) The method according to item 111, wherein the physiological data includes at least one of accelerometer data from an accelerometer and electrocardiogram (ECG) data from an ECG circuit. (Item 113) The method according to item 111 or 112, further comprising measuring the direction of each level crossing. (Item 114) The method according to any one of items 111 to 113, further comprising increasing the number of level crossings in response to a determination that a level crossing at the end of a first frame of physiological data is in the same direction as a level crossing at the start of a second frame of physiological data, wherein the first and second frames are sequentially arranged within the physiological data. (Item 115) The method according to any one of items 111 to 114, further comprising detecting a change in the slope of the frame of physiological data and increasing the number of level crossings in response to the change in slope. (Item 116) The method according to any one of items 111 to 115, wherein the change in slope is before a level crossing at the start of a frame of physiological data. (Item 117) The method according to any one of items 111 to 116, wherein the change in slope is after a level crossing at the end of the frame of physiological data. (Item 118) The method according to any one of items 111 to 117, wherein the ingestible sensor data is generated by an ingestible event marker after contact with the patient's body fluid. (Item 119) The method according to any one of items 111 to 118, further comprising removably attaching a wearable device to the patient's skin, and receiving the discontinuous data includes receiving the discontinuous data by the wearable device. (Item 120) A system for measuring a patient's heart rate variability, A wearable device comprising electrodes, configured to be coupled to the patient's body and configured to detect discontinuous data using at least the electrodes, the discontinuous data including a frame of ingestible sensor data and a frame of the patient's physiological data scattered in a time gap between the frames of the ingestible sensor data, a wearable device; At least one processor of the wearable device and a remote device communicatively coupled to the wearable device, the processor configured to group at least two of the frames of the physiological data into blocks and measure the patient's heart rate variability using the blocks. A system comprising. (Item 121) The system according to item 120, further comprising the processor configured to measure the validity of the heart rate data in each frame of the physiological data within the block. (Item 122) The system according to item 121, further comprising the processor configured to determine that the number of frames including valid heart rate data within the block is equal to or greater than a threshold. (Item 123) The system according to item 122, further comprising the processor configured to determine that the number of frames including valid heart rate data within the second block is less than the threshold value, and to ignore the second block while calculating the heart rate variability of the patient. (Item 124) The system according to any one of items 121 to 123, further comprising the processor configured to aggregate the frames determined to include valid heart rate data, and the processor is configured to measure the heart rate variability based on the aggregated frames. (Item 125) The system according to any one of items 120 to 124, further comprising the processor configured to determine that impedance measurement values disposed proximally to the block are less than or equal to an impedance threshold value. (Item 126) The system according to item 125, further comprising the processor configured to determine that a second impedance measurement value disposed proximally to the second block is greater than the impedance threshold value, and to ignore the second block while measuring the heart rate variability of the patient. (Item 127) The system according to any one of items 120 to 126, further comprising the processor configured to process the block to remove frames including heart rate values that are outliers from the heart rate variability measurement. (Item 128) The system according to any one of items 120 to 127, further comprising the processor configured to process the block via a cleaning algorithm selected from a merge twin interval algorithm, a split toll interval algorithm, an absorb short interval algorithm, and a bimodality detection algorithm. (Item 129) The system according to any one of items 120 to 128, wherein the wearable device includes an electrocardiogram (ECG) circuit operably connected to the electrodes. (Item 130) The system according to item 129, wherein the physiological data includes ECG data from the ECG circuit. (Item 131) The system according to any one of items 120 to 130, wherein the wearable device is configured to be removably attached to the skin of the patient. (Item 132) A wearable device comprising a processor coupled to a non-transitory memory, wherein when the non-transitory memory is executed by the processor, the processor is caused to receive discontinuous data including a frame of ingestible sensor data and a frame of physiological data from the patient scattered at a time gap between the frames of the ingestible sensor data, group at least two of the frames of the physiological data into blocks, and measure a heart rate variation of the patient using the blocks, the wearable device including machine-executable instructions. (Item 133) The machine-executable instructions, when executed by the processor, cause the processor to measure the validity of heart rate data within each frame of physiological data within the block, for the wearable device according to item 132. (Item 134) The machine-executable instructions, when executed by the processor, cause the processor to determine that the number of frames including valid heart rate data within the block is equal to or greater than a threshold, for the wearable device according to item 133. (Item 35) The machine-executable instructions, when executed by the processor, cause the processor to determine that the number of frames including valid heart rate data within a second block is less than the threshold, and to ignore the second block when calculating the heart rate variation of the patient, for the wearable device according to item 134. (Item 136) The instructions executable by the machine, when executed by the processor, cause the processor to aggregate the frames determined to include valid heart rate data and measure the heart rate variability based on the aggregated frames, for the wearable device according to any one of items 133 to 135. (Item 137) The instructions executable by the machine, when executed by the processor, cause the processor to determine that impedance measurement values disposed proximal to the block are less than or equal to an impedance threshold value, for the wearable device according to any one of items 132 to 135. (Item 138) The instructions executable by the machine, when executed by the processor, cause the processor to determine that a second impedance measurement value disposed proximal to a second block is greater than the impedance threshold value and ignore the second block while measuring the heart rate variability of the patient, for the wearable device according to item 137. (Item 139) The instructions executable by the machine, when executed by the processor, cause the processor to process the block to remove frames including heart rate values that are outliers from the heart rate variability measurement, for the wearable device according to any one of items 132 to 138. (Item 140) The instructions executable by the machine, when executed by the processor, cause the processor to process the block via a cleaning algorithm selected from a merge twin interval algorithm, a split toll interval algorithm, an absorb short interval algorithm, and a bimodality detection algorithm, for the wearable device according to any one of items 132 to 139. (Item 141) The wearable device includes an electrocardiogram (ECG) circuit operably coupled to the electrodes, for the wearable device according to any one of items 132 to 140. (Item 142) The wearable device according to item 141, wherein the physiological data includes ECG data from the ECG circuit. (Item 143) The wearable device according to any one of items 132 to 147, wherein the wearable device is configured to be removably attached to the skin of the patient. (Item 144) A method for measuring a patient's heart rate variability, comprising: receiving discontinuous data including a frame of ingestible sensor data and a frame of physiological data from the patient scattered in a time gap between the frames of the ingestible sensor data; grouping at least two of the frames of the physiological data into a block and measuring the patient's heart rate variability using the block; and a method. (Item 145) The method according to item 144, further comprising measuring the validity of the heart rate data in each frame of the physiological data within the block. (Item 146) The method according to item 145, further comprising determining that the number of frames including valid heart rate data within the block is equal to or greater than a threshold value. (Item 147) The method according to item 146, further comprising determining that the number of frames including valid heart rate data within a second block is less than the threshold value, and ignoring the second block when calculating the patient's heart rate variability. (Item 148) The method according to item 146 or 147, further comprising aggregating the frames determined to include valid heart rate data and measuring the heart rate variability based on the aggregated frames. (Item 149) The method according to any one of items 144 to 148, further comprising determining that impedance measurement values disposed proximal to the block are equal to or less than an impedance threshold value. (Item 150) The method according to item 149, further comprising determining that a second impedance measurement value proximally disposed to the second block is greater than the impedance threshold value and ignoring the second block while measuring the heartbeat variation of the patient. (Item 151) The method according to any one of items 144 to 150, further comprising processing the block to remove a frame including a heart rate of an outlier from the heartbeat variation measurement. (Item 152) The method according to any one of items 144 to 151, further comprising processing the block via a cleaning algorithm selected from a merge twin interval algorithm, a split toll interval algorithm, an absorb short interval algorithm, and a bimodality detection algorithm. (Item 153) The method according to any one of items 144 to 152, wherein the physiological data includes ECG data from an ECG circuit. (Item 154) The method according to any one of items 144 to 153, further comprising removably attaching a wearable device to the skin of the patient, and receiving the discontinuous data includes receiving the discontinuous data by the wearable device. (Item 155) A system for measuring a patient's rest, A wearable device including an accelerometer, configured to be coupled to the patient's body, configured to detect discontinuous data using at least the accelerometer and the electrodes, the discontinuous data including a frame of ingestible sensor data and a frame of the patient's physiological data scattered in a time gap between the frames of the ingestible sensor data, the physiological data including accelerometer data from the accelerometer, the wearable device, and At least one processor of the wearable device and a remote device communicably connected to the wearable device, the processor configured to determine that the patient is at rest based on accelerometer data, A system comprising. (Item 156) The system according to item 155, further comprising the processor configured to measure total activity data from the body angle data and the accelerometer data of the patient and determine that the patient is at rest based on the body angle data and the total activity data. (Item 157) The system according to item 156, further comprising the processor configured to add body angle data to a body angle aggregation window until a threshold period is covered by the body angle data and measure aggregated body angle data based on the body angle aggregation window, wherein determining that the patient is at rest is based on the aggregated body angle data. (Item 158) The system according to item 156 or 157, further comprising the processor configured to add total activity data to a total activity aggregation window until a threshold period is covered by the total activity data and measure aggregated total activity data based on the total activity aggregation window, wherein the patient is determined to be at rest based on the aggregated total activity data. (Item 159) The system according to any one of items 156 to 158, further comprising the processor configured to remove values of the total activity data that are above a threshold. (Item 160) The system according to any one of items 156 to 159, further comprising the processor configured to determine that the body angle data within the body angle aggregation window is valid. (Item 161) The system according to any one of items 156 to 160, further comprising the processor configured to ignore second body angle data within the ineffective body angle aggregation window. (Item 162) The system according to any one of items 156 to 161, further comprising the processor configured to determine that total activity data within the total activity aggregation window is valid. (Item 163) The system according to any one of items 156 to 162, further comprising the processor configured to ignore second total activity data within the ineffective total activity aggregation window. (Item 164) The system according to any one of items 155 to 163, further comprising the processor configured to classify the physiological data as resting data or non - resting data based on the determination that the patient is at rest. (Item 165) The physiological data further includes electrocardiogram (ECG) data, and the processor is configured to measure a resting heart rate from the ECG data in the physiological data while the patient is determined to be at rest, according to the system of item 164. (Item 166) The processor is configured to measure the resting heart rate from the largest segment of physiological data within 24 hours classified as resting data, according to the system of item 165. (Item 167) The wearable device is configured to be removably attached to the skin of the patient, according to the system of any one of items 155 to 166. (Item 168) A wearable device comprising a processor coupled to a non - transitory memory, wherein the non - transitory memory, when executed by the processor, causes the processor to Receive discontinuous data including a frame of ingestible sensor data and a frame of physiological data from a patient scattered at a time gap between the frames of the ingestible sensor data, Cause the patient to be determined to be at rest based on accelerometer data, A wearable device including machine-executable instructions. (Item 169) The machine-executable instructions, when executed by the processor, cause the processor to measure the body angle data and total activity data of the patient from the accelerometer data, and determine that the patient is at rest based on the body angle data and total activity data. The wearable device according to item 168. (Item 170) The machine-executable instructions, when executed by the processor, cause the processor to add body angle data to a body angle aggregation window until a threshold period is covered by the body angle data, measure aggregated body angle data based on the body angle aggregation window, and determine that the patient is at rest. This is based on the aggregated body angle data. The wearable device according to item 169. (Item 171) The machine-executable instructions, when executed by the processor, cause the processor to add total activity data to a total activity aggregation window until a threshold period is covered by the total activity data, measure aggregated total activity data based on the total activity aggregation window, and determine that the patient is at rest based on the aggregated total activity data. The wearable device according to item 169 or 170. (Item 172) The machine-executable instructions, when executed by the processor, cause the processor to remove values of the total activity data that are above a threshold. The wearable device according to any one of items 169 to 171. (Item 173) When the instructions executable by the machine are executed by the processor, the processor is caused to determine that the body angle data in the body angle aggregation window is valid, the wearable device according to any one of items 169 to 172. (Item 174) When the instructions executable by the machine are executed by the processor, the processor is caused to ignore the second body angle data in the body angle aggregation window that is invalid, the wearable device according to any one of items 169 to 173. (Item 175) When the instructions executable by the machine are executed by the processor, the processor is caused to determine that the total activity data in the total activity aggregation window is valid, the wearable device according to any one of items 169 to 174. (Item 176) When the instructions executable by the machine are executed by the processor, the processor is caused to ignore the second total activity data in the total activity aggregation window that is not valid, the wearable device according to any one of items 169 to 175. (Item 177) When the instructions executable by the machine are executed by the processor, the processor is caused to classify the physiological data as resting data or non-resting data based on the determination that the patient is at rest, the wearable device according to any one of items 169 to 176. (Item 178) The physiological data further includes electrocardiogram (ECG) data, and when the instructions executable by the machine are executed by the processor, the processor is caused to measure the resting heart rate from the ECG data in the physiological data while the patient is determined to be at rest, the wearable device according to item 177. (Item 179) The instructions executable on the machine, when executed by the processor, cause the processor to measure the resting heart rate from the largest segment of physiological data within 24 hours classified as resting data, for the wearable device of item 178. (Item 180) The wearable device according to any one of items 168 to 179, wherein the wearable device is configured to be removably attached to the skin of the patient. (Item 181) A method for measuring a patient's rest, comprising: receiving discontinuous data including a frame of ingestible sensor data and a frame of physiological data from the patient scattered in the time gap between the frames of the ingestible sensor data; determining that the patient is at rest based on the accelerometer data. Method. (Item 182) The method according to item 181, further comprising measuring the body angle data and total activity data of the patient from the accelerometer data, and determining that the patient is at rest based on the body angle data and total activity data. (Item 183) The method according to item 182, further comprising adding body angle data to a body angle aggregation window until a threshold period is covered by the body angle data, and measuring aggregated body angle data based on the body angle aggregation window, wherein determining that the patient is at rest is based on the aggregated body angle data. (Item 184) The method according to item 182 or 183, further comprising adding total activity data to a total activity aggregation window until a threshold period is covered by the total activity data, and measuring aggregated total activity data based on the total activity aggregation window, wherein determining that the patient is at rest is based on the aggregated total activity data. (Item 185) The method according to any one of Items 182 to 184, further comprising removing values in the total activity data above a threshold value. (Item 186) The method according to any one of Items 182 to 185, further comprising determining that the body angle data within the body angle aggregation window is valid. (Item 187) The method according to any one of Items 182 to 186, further comprising ignoring second body angle data within the body angle aggregation window that is not valid. (Item 188) The method according to any one of Items 182 to 187, further comprising determining that the total activity data within the total activity aggregation window is valid. (Item 189) The method according to any one of Items 182 to 188, further comprising ignoring second total activity data within the total activity aggregation window that is not valid. (Item 190) The method according to any one of Items 181 to 189, further comprising classifying the physiological data as resting data or non-resting data based on the determination that the patient is at rest. (Item 191) The method according to Item 190, wherein the physiological data further includes electrocardiogram (ECG) data, and further comprising measuring a resting heart rate from the ECG data in the physiological data while the patient is determined to be at rest. (Item 192) The method according to Item 191, further comprising measuring the resting heart rate from the maximum segment of the physiological data within 24 hours classified as resting data. (Item 193) The method according to any one of items 181 to 192, further comprising removably attaching a wearable device to the skin of the patient, and receiving the discontinuous data includes receiving the discontinuous data by the wearable device.

Claims

1. 1. A system for determining patient rest, comprising: a wearable device comprising an accelerometer, the wearable device configured to be coupled to a body of the patient and configured to detect discontinuous data utilizing at least the accelerometer and electrodes, the discontinuous data including frames of ingestible sensor data and frames of physiological data from the patient interspersed in time gaps between the frames of ingestible sensor data, the physiological data including accelerometer data from the accelerometer; A processor of at least one of the wearable device and a remote device communicatively connected to the wearable device, the processor comprising: receiving the discontinuous data from the wearable device; generating average body angle data using the accelerometer data within the discrete data; determining that an amount of generated average body angle data above an aggregation threshold has been collected; calculating a data ratio of a total number of collected data points in said average body angle data to an expected number of data points in an aggregation window period; determining that the amount of generated average body angle data can be used reliably based on the calculated data ratio exceeding a data ratio threshold; classifying the average body angle data into at least one of a plurality of classifications including "lying down" and "not lying down"; a processor configured to determine that the patient is at rest by A system comprising:

2. 10. The system of claim 1, further comprising the processor configured to determine total activity data from the accelerometer data and determine that the patient is at rest further based on the body angle data and the total activity data.

3. 3. The system of claim 2, further comprising the processor configured to add the total activity data to a total activity aggregation window until a threshold time period is covered by the total activity data, and determine aggregated total activity data based on the total activity aggregation window, wherein the patient is determined to be at rest further based on the aggregated total activity data.

4. The system of claim 3 , further comprising the processor configured to remove values ​​of the total activity data that are equal to or greater than a total activity data threshold.

5. The system of claim 1 , further comprising the processor configured to determine that the body angle data within a body angle aggregation window is valid.

6. The system of claim 5 , further comprising the processor configured to ignore second body angle data within the body angle aggregation window that is not valid.

7. The system of claim 3 , further comprising the processor configured to determine that the total activity data within a total activity aggregation window is valid.

8. The system of claim 7 , further comprising the processor configured to ignore second total activity data within the total activity aggregation window that is not valid.

9. The system of claim 1 , further comprising the processor configured to classify the physiological data as resting data or non-resting data based on a determination that the patient is at rest.

10. 2. The system of claim 1, wherein the physiological data further includes electrocardiogram (ECG) data, and the processor is configured to determine a resting heart rate from the ECG data in the physiological data during a period of time during which the patient is determined to be at rest.

11. The system of claim 1 , wherein the processor is configured to determine a resting heart rate from a largest segment of the physiological data within a 24-hour period that is classified as resting data.

12. The system of claim 1 , wherein the wearable device is configured to be removably attached to the patient's skin.

13. 1. A wearable device including a processor coupled to a non-transitory memory, the non-transitory memory comprising machine-executable instructions that, when executed by the processor, perform: receiving discontinuous data including frames of ingestible sensor data and frames of physiological data from a patient interspersed in time gaps between the frames of ingestible sensor data, the physiological data including accelerometer data; generating average body angle data using the accelerometer data within the discrete data; determining that an amount of generated average body angle data above an aggregation threshold has been collected; calculating a data ratio of a total number of collected data points in said average body angle data to an expected number of data points in an aggregation window period; determining that the amount of generated average body angle data can be used reliably based on the calculated data ratio exceeding a data ratio threshold; classifying the average body angle data into at least one of a plurality of classifications including "lying down" and "not lying down"; A wearable device comprising:

14. 1. A method for determining patient rest, comprising: receiving discontinuous data, the discontinuous data including frames of ingestible sensor data and frames of physiological data from a patient interspersed in time gaps between the frames of ingestible sensor data, the physiological data including accelerometer data; generating average body angle data using the accelerometer data within the discrete data; determining that an amount of generated average body angle data above an aggregation threshold has been collected; calculating a data ratio of a total number of collected data points in said average body angle data to an expected number of data points in an aggregation window period; determining that the amount of generated average body angle data can be used reliably based on the calculated data ratio exceeding a data ratio threshold; classifying the average body angle data into at least one of a plurality of classifications including "lying down" and "not lying down"; The method includes:

Images