Patent Application
20230042067
The present technology is generally related to an electronic device that is affixed to, mounted to, inserted into, or otherwise deployed onto the body of a user. More specifically, the present technology relates to the use of at least one sensor (such as an accelerometer) onboard a user-mountable electronic device for purposes of providing guidance to the user when deploying the electronic device onto the body.
A variety of personal or portable electronic devices are intended for application to the body or skin of a user. For example, electronic medical devices (such as physiological characteristic or analyte sensors, monitor devices, fluid infusion pumps, and activity monitors) can be designed as user-mounted or user-attached devices. In this regard, analyte sensors have been designed for use in obtaining an indication of blood glucose (BG) and subcutaneous sensor glucose (SG) levels and monitoring glucose levels in a diabetic patient, with the distal segment portion of the sensor positioned subcutaneously in direct contact with patient extracellular fluid.
A continuous glucose monitor (CGM) device with a glucose sensor of the type described above may be packaged and sold as an assembled product that includes certain features or components that allow the patient to position, deploy, and subcutaneously implant the sensor. For example, glucose sensors are often subcutaneously/transcutaneously implanted using a needle that punctures the skin of the patient as the sensor is deployed and forced onto the body. The glucose sensor device is compatible with an deployment or insertion device that cooperates with an insertion needle to insert the sensor.
Some user-mountable electronic devices, including CGM devices and “patch pump” style fluid infusion devices, may be sensitive to the particular deployment location on the body of the user and/or the particular orientation of the device relative to the body part on which it is deployed. For example, it may be desirable to deploy a CGM device on a certain body part (e.g., the thigh or the abdomen) and in a certain physical orientation or layout. Preferred mounting locations and/or device orientations may be more convenient, result in better outcomes, provide better user comfort, or the like.
Accordingly, it is desirable to have a low-cost and reliable mechanism and methodology that guides or instructs a user during deployment of a user-mountable electronic device. Furthermore, other desirable features and characteristics will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and the foregoing technical field and background.
The subject matter of this disclosure generally relates to user-mountable devices, such as a device with a continuous glucose monitoring (CGM) sensor that is inserted into the subcutaneous tissue. The device (or an assembly that includes the device) has at least one onboard orientation, motion, movement, or acceleration sensor, such as an accelerometer. The sensor output is processed to identify a body part on which the device will be deployed, and to provide a preferred or recommended orientation of the device (relative to the identified body part). Appropriate guidance or user instructions are output to a user device to assist the user during deployment of the device onto the body.
In one aspect, the present disclosure provides a system having a user-mountable electronic device that includes a housing and at least one sensor device located within the housing and configured to generate sensor output that indicates orientation or motion of the user-mountable electronic device. The system also has an output interface and at least one processor. The at least one processor is operated to: receive the sensor output generated by the at least one sensor device; identify, based on the received sensor output, a body part on which the user intends to deploy the user-mountable electronic device; determine a preferred orientation of the user-mountable electronic device relative to the identified body part; and cause the output interface to provide deployment guidance that indicates the preferred orientation of the user-mountable electronic device.
In another aspect, the disclosure provides a method that involves: receiving, from at least one sensor device of a user-mountable electronic device, sensor output that indicates orientation or motion of the user-mountable electronic device; identifying, based on the received sensor output, a body part on which the user intends to deploy the user-mountable electronic device; determining a preferred orientation of the user-mountable electronic device relative to the identified body part; and causing an output interface to provide deployment guidance that indicates the preferred orientation of the user-mountable electronic device.
In another aspect, the disclosure provides a computer-based system that includes: computer-readable storage media to store program code instructions; and at least one processor. The program code instructions are configurable to cause the at least one processor to perform a method that involves the steps of: receiving, from at least one sensor device of a user-mountable electronic device, sensor output that indicates orientation or motion of the user-mountable electronic device; identifying, based on the received sensor output, a body part on which the user intends to deploy the user-mountable electronic device; determining a preferred orientation of the user-mountable electronic device relative to the identified body part; and causing an output interface to provide deployment guidance that indicates the preferred orientation of the user-mountable electronic device.
In another aspect, the disclosure provides a method that involves: receiving, from at least one sensor device of a first user-mountable electronic device, sensor output that indicates orientation or motion of the first user-mountable electronic device, and corresponding performance data for the first user-mountable device; identifying, based on the received sensor output and corresponding performance data, a preferred body part or orientation for deployment of a second user-mountable electronic device; and causing an output interface to provide deployment guidance that indicates the preferred body part or orientation for deployment of the second user-mountable electronic device.
The details of one or more aspects of the disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the techniques described in this disclosure will be apparent from the description and drawings, and from the claims.
The following detailed description is merely illustrative in nature and is not intended to limit the embodiments of the subject matter or the application and uses of such embodiments. As used herein, the word “exemplary” means “serving as an example, instance, or illustration.” Any implementation described herein as exemplary is not necessarily to be construed as preferred or advantageous over other implementations. Furthermore, there is no intention to be bound by any expressed or implied theory presented in the preceding technical field, background, brief summary or the following detailed description.
It should be understood that various aspects disclosed herein may be combined in different combinations than the combinations specifically presented in the description and accompanying drawings. It should also be understood that, depending on the example, certain acts or events of any of the processes or methods described herein may be performed in a different sequence, may be added, merged, or left out altogether (e.g., all described acts or events may not be necessary to carry out the techniques). In addition, while certain aspects of this disclosure are described as being performed by a single module or unit for purposes of clarity, it should be understood that the techniques of this disclosure may be performed by a combination of units or modules associated with, for example, a medical device.
In one or more examples, the described techniques may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include non-transitory computer-readable media, which corresponds to a tangible medium such as data storage media (e.g., RAM, ROM, EEPROM, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer).
Program code instructions may be configurable to be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the term “processor” as used herein may refer to any of the foregoing structure or any other physical structure suitable for implementation of the described techniques. Also, the techniques could be fully implemented in one or more circuits or logic elements.
Techniques and technologies may be described herein in terms of functional and/or logical block components, and with reference to symbolic representations of operations, processing tasks, and functions that may be performed by various computing components or devices. Such operations, tasks, and functions are sometimes referred to as being computer-executed, computerized, software-implemented, or computer-implemented. It should be appreciated that the various block components shown in the figures may be realized by any number of hardware, software, and/or firmware components configured to perform the specified functions. For example, an embodiment of a system or a component may employ various integrated circuit components, e.g., memory elements, digital signal processing elements, logic elements, look-up tables, or the like, which may carry out a variety of functions under the control of one or more microprocessors or other control devices.
At least some of the components of the system 100 are communicatively coupled with one another to support data communication, signaling, and/or transmission of control commands as needed, via at least one communications network 120. The at least one communications network 120 may support wireless data communication and/or data communication using tangible data communication links.
As explained in more detail below, the user-mountable electronic device or assembly 102 includes at least one sensor device 104 that is configured, arranged, and operated to generate sensor output that indicates orientation, motion, velocity, acceleration, and/or other physical status of the user-mountable electronic device or assembly 102. To this end, the at least one sensor device 104 may include or be realized as one or more of the following, without limitation: an accelerometer (single-axis, multiple-axis, etc.); an inertial measurement unit (IMU), which may be an electronic device that measures an object's specific force, angular rate, orientation, and/or other characteristics, typically using a combination of accelerometers, gyroscopes, magnetometers, etc.; a gyroscope; a magnetometer; a gravimeter; a global positioning system unit; or the like.
The system 100 can support any number of user devices 106 that are linked to, used by, owned by, or otherwise associated with the particular user or patient. In this regard, a user device 106 may be, without limitation: a smartphone device; a laptop, desktop, or tablet computer device; a medical device; a wearable device; a global positioning system (GPS) receiver device; a system, component, or feature onboard a vehicle; a smartwatch device; a television system; a household appliance; a video game device; a media player device; or the like. For the example described here, the user-mountable electronic device or assembly 102 and the at least one user device 106 are owned by, operated by, or otherwise linked to the same user/patient. Any given user device 106 can host, run, or otherwise execute the patient care application 108. In certain embodiments, for example, the user device 106 is implemented as a smartphone with the patient care application 108 installed thereon. In accordance with another example, the patient care application 108 is implemented in the form of a website or webpage, e.g., a website of a healthcare provider, or a website of the manufacturer, supplier, or retailer of the user-mountable electronic device or assembly 102. In accordance with another example, the user-mountable electronic device or assembly 102 executes the patient care application 108 as a native function.
In accordance with the illustrated embodiment, the output interface 110 resides at the user device 106. Alternatively or additionally, an output interface 110 may reside elsewhere in the system 100. For example, an output interface 110 may be deployed at the user-mountable device or assembly 102 and/or at one or more additional or supplemental electronic devices that are supported by the system 100. The output interface 110 is suitably configured, controlled, and operated to generate and provide suitably formatted output, content, or information to the user. In this regard, the output interface 110 may include or cooperate with one or more of the following, without limitation: a display element; a touch screen; an audio transducer (e.g., a speaker); indicator light(s); a haptic feedback element; or the like. The output interface 110 may be utilized to generate, present, render, output, and/or annunciate alerts, alarms, messages, images, video clips, or notifications as needed. For example, the output interface 110 can be controlled and operated to provide deployment guidance that indicates a preferred body part for deployment of the user-mountable device or assembly 102, that indicates a preferred deployment orientation of the user-mountable device or assembly 102, and/or that indicates user instructions for deploying the user-mountable device or assembly 102. The deployment guidance may be conveyed in the form of an animated display, one or more images, a video clip, written instructions, audio instructions, etc. The deployment guidance may be generated and provided in real-time or substantially real-time in response to sensor output generated by the at least one sensor device 104 while the user prepares the user-mountable electronic device or assembly 102 for deployment and/or during the deployment operation. Alternatively or additionally, the deployment guidance may be generated and provided in non-real-time in response to historical sensor output collected from one or more previously deployed user-mountable electronic devices or assemblies over a designated period of time, e.g., several days, a week, a month, etc. In some examples, the historical sensor output may include sensor performance data and corresponding to historic deployment data (e.g., body part and/or orientation information).
The at least one processor 118 may be implemented or performed with a general purpose processor, a content addressable memory, a microcontroller unit, a digital signal processor, an application specific integrated circuit, a field programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination designed to perform the functions described here. Moreover, the at least one processor 118 may be implemented as a combination of computing devices, e.g., a combination of a digital signal processor and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a digital signal processor core, or any other such configuration. For ease of illustration,
In certain implementations, the system 100 includes a medication delivery system (not separately shown in
The at least one patient history and outcomes database 114 may include historical data related to the user's physical condition, physiological response to medication regulated by the medication delivery system, activity patterns or related information, eating patterns and habits, work habits, and the like. Furthermore, the database 114 may be maintained and operated such that it includes preferred orientations for user-mountable electronic devices, and for different body part deployments. Preferred deployments and device orientations may result in: better device performance (e.g., sensor accuracy); increased device lifespan; improved wireless connectivity or wireless performance; improved user comfort; better patient outcomes; improved appearance or aesthetics; or the like. The preferred orientation data may be personal to the particular user, and based on historical device deployments and corresponding results, medical outcomes, and the like. Alternatively or additionally, the preferred orientation data may include data collected for a population of users (other than the particular user of the system 100). Although preferred device orientation usually applies to physically asymmetric devices, it may also apply to symmetric devices (e.g., round or circular devices) having operating characteristics or functionality that may be impacted by the device orientation.
In accordance with embodiments where the medication delivery system is an insulin infusion device, the database 114 can maintain any of the following, without limitation: historical glucose data and corresponding date/time stamp information; insulin delivery and dosage information; user-entered stress markers or indicators; device orientation data (provided by the at least one sensor device 104) and corresponding date/time stamp information; diet or food intake history for the user; location information; and/or any other information that may be generated by or used by the system 100.
A patient history and outcomes database 114 may reside at the user device 106, at a medication delivery system, at a data processing system, or at any network-accessible location (e.g., a cloud-based database or server system). In certain embodiments, a patient history and outcomes database 114 may be included with the patient care application 108. The patient history and outcomes database 114 enables the system 100 to generate recommendations, warnings, and/or device deployment guidance for the user. The database 144 may also enable the system 100 to regulate the manner in which the medication delivery system functions to administer therapy to the user, based on the detected sensor output (generated by the at least one sensor device 104).
The following description relates to methodologies for deploying a user-mountable electronic device, such as a medical device or component, that is designed to be affixed to the body of a user. In this regard, the electronic device is deployable onto a body part of the user via, for example, a suitably configured deployment device that is compatible with the electronic device. Referring to
As schematically depicted by the downward pointing arrow in
Actuation of the deployment device 204 releases the electronic device 202 such that it moves toward the body part 206 with a deployment acceleration that is sufficient to adhere the adhesive surface 212 (of the adhesive patch 210) to the body part 206. If the electronic device 202 includes an insertable analyte sensor, an insertable fluid delivery cannula, and/or another body-insertable element, then the deployment acceleration is also sufficient to facilitate insertion of such insertable element(s) into the body part 206.
In accordance with certain embodiments, the user-mountable electronic device or assembly 102 includes or is realized as an analyte sensor that measures a physiological characteristic of the user, such as glucose. In accordance with some embodiments, the user-mountable electronic device or assembly 102 is realized as a continuous glucose monitor having at least one glucose sensor. In such embodiments, the system 100 may include or cooperate with a physically distinct insulin infusion device (e.g., a pump with a tethered insulin infusion set, a user-activated insulin pen, a patch pump, or the like) that can receive the sensor output from the user-mountable electronic device for appropriate handling, processing, and/or routing.
In accordance with some embodiments, the user-mountable electronic device or assembly 102 is realized as a single component that includes: (1) an analyte sensor that measures a physiological characteristic of the user, such as glucose; and (2) a medicament delivery element, such as a fluid delivery cannula, conduit, or needle. In accordance with some embodiments, the user-mountable electronic device or assembly 102 is realized as a single component that includes: (1) an analyte sensor that measures a physiological characteristic of the user, such as glucose; (2) a medicament delivery element, such as a fluid delivery cannula, conduit, or needle; and (3) a fluid pump mechanism or system that is electronically controlled to regulate the delivery of a medicament to the user via the fluid delivery cannula, conduit, or needle. In accordance with some embodiments, the user-mountable electronic device or assembly 102 includes or is realized as a fluid infusion device, such as an insulin infusion pump. In accordance with some embodiments, the user-mountable electronic device or assembly 102 includes or is realized as a medication fluid infusion set having a body-insertable fluid conduit.
Accordingly, the user-mountable electronic device or assembly 102 may be a component of a system used to treat diabetes (such as, a continuous glucose sensor with wireless communication capability, an insulin infusion device, or a blood glucose meter/monitor), although embodiments of the disclosed subject matter are not so limited. For the sake of brevity, conventional features and characteristics related to infusion systems, analyte sensors such as continuous glucose sensors, and fluid conduits such as soft cannulas may not be described in detail here.
The user-mountable electronic device or assembly 102 may include one or more elements or components that are intended for insertion into or application onto the body of the user. For example, the electronic device or assembly 102 may include an analyte sensor that is designed to be inserted into the skin of the user. In certain embodiments, the electronic device or assembly 102 includes or is realized as a continuous glucose monitor having a glucose sensor that is insertable into the user to obtain sensor glucose measurements. Accordingly, actuation of the deployment device initiates insertion of the analyte sensor into the user. As another example, the electronic device or assembly 102 may be implemented as a fluid infusion device having a fluid delivery cannula or needle that is designed to be inserted into the skin of the user. In certain embodiments, the electronic device or assembly 102 includes a fluid delivery cannula that is insertable into the user to deliver insulin from a fluid reservoir to the user. Accordingly, actuation of the deployment device initiates insertion of the fluid delivery cannula or needle into the user.
In certain embodiments, the user-mountable electronic device or assembly 102 is realized as (or includes) a transdermal medicament delivery device that is configured to deliver a medicament to the user through the skin without using an inserted needle, cannula, or conduit. Similarly, the user-mountable electronic device or assembly 102 may be realized as (or include) a transdermal analyte sensor device that is configured to detect or measure a physiological characteristic of the user through the skin or via contact with the skin, without using an inserted sensor element, electrode, or lead. As additional examples, the user-mountable electronic device or assembly 102 may include or be realized as any of the following, without limitation: a body temperature monitor; a heartrate monitor; a pulse oximeter; a sweat sensor; and/or an activity tracker. A user-mountable electronic device of this type may include an adhesive strip or component that secures the device to the skin of the user after deployment. In some embodiments, the user-mountable electronic device is realized as an implantable device that is injected or implanted into the body of the user via the application of force that results in a detectable deployment acceleration.
The embodiment of the sensor device 300 shown in
The electronics assembly 306 can be implemented as a printed circuit board to carry electronic components and elements that support operation of the sensor device 300, e.g., any number of discrete or integrated devices, electrical conductors or connectors, and the like. For example, the electronics assembly 306 may include the following items, without limitation: at least one processor 330; memory 334 to store data, processor-readable program instructions, and the like; a wireless communication interface 338 to wirelessly receive and/or transmit signals, data, instructions, and the like; a battery 342 or other power source; and an accelerometer 346 to measure acceleration, motion, and/or orientation of the sensor device 300. While
The proximal end 350 of the analyte sensor 318 is electrically couplable to the sensor interface 314 to establish electrical connectivity between conductors of the analyte sensor 318 and the electronics assembly 306. Although depicted as a separate block in
Referring again to the electronics assembly 306, each processor 330 may be implemented or performed with a general purpose processor, a content addressable memory, a microcontroller unit, a digital signal processor, an application specific integrated circuit, a field programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination designed to perform the functions described here. Moreover, a processor 330 or a plurality of processors 330 may be implemented as a combination of computing devices, e.g., a combination of a digital signal processor and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a digital signal processor core, or any other such configuration. In certain embodiments, one or more processors 330 of the sensor device 300 can be used to implement the at least one data processing system and/or processor 118 (depicted in
The memory 334 may be realized as at least one memory element, device, or unit, such as: RAM memory, flash memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, optically readable media, or any other form of storage medium known in the art. In this regard, the memory 334 can be coupled to the at least one processor 330 such that the at least one processor 330 can read information from, and write information to, the memory 334. In the alternative, the memory 334 may be integral to the at least one processor 330. As an example, the at least one processor 330 and the memory 334 may reside in an ASIC. At least a portion of the memory 334 can be realized as a computer storage medium that is operatively associated with the at least one processor 330, e.g., a tangible, non-transitory computer-readable medium having computer-executable instructions stored thereon. The computer-executable instructions are configurable to be executed by the at least one processor 330 to cause the at least one processor 330 to perform certain tasks, operations, functions, and processes that are specific to the particular embodiment. In this regard, the memory 334 may represent one suitable implementation of such computer-readable media.
The wireless communication interface 338 facilitates data communication between the sensor device 300 and other components as needed during the operation of the sensor device 300. In the context of this description, the wireless communication interface 338 can be employed to transmit or receive device-related control data, sensor data obtained in connection with operation of the analyte sensor 318, data or output provided by the accelerometer 346, device-related status or operational data, calibration data, and the like. It should be appreciated that the particular configuration and functionality of the wireless communication interface 338 can vary depending on the hardware platform and specific implementation of the sensor device 300. An embodiment of the sensor device 300 may support wireless data communication using various data communication protocols. For example, the wireless communication interface 338 could support one or more wireless data communication protocols, techniques, or methodologies, including, without limitation: RF; IrDA (infrared); Bluetooth; BLE; ZigBee (and other variants of the IEEE 802.15 protocol); IEEE 802.11 (any variation); IEEE 802.16 (WiMAX or any other variation); Direct Sequence Spread Spectrum; Frequency Hopping Spread Spectrum; cellular/wireless/cordless telecommunication protocols; wireless home network communication protocols; paging network protocols; magnetic induction; satellite data communication protocols; wireless hospital or health care facility network protocols such as those operating in the WMTS bands; GPRS; and proprietary wireless data communication protocols such as variants of Wireless USB. Although not separately shown, embodiments of the sensor device 300 may also support one or more wired/cabled data communication protocols, including, without limitation: Ethernet; powerline; home network communication protocols; USB; IEEE 1394 (Firewire); hospital network communication protocols; and proprietary data communication protocols.
In accordance with certain embodiments, the sensor device 300 communicates sensor glucose values to a destination device, such as an insulin infusion device, based on a designated schedule (for example, every five minutes, every minute, etc.). As mentioned above, communication of sensor glucose data is typically carried out wirelessly, e.g., via a BLUETOOTH wireless communication link using the wireless communication interface 338. For each sampling time, the sensor device 300 can send the most recent sensor glucose value with or without one or more historical sensor glucose values. For example, every five minutes, the sensor device 300 may send any number of sensor glucose values that have been obtained and collected during the last five-minute interval. As another example, every five minutes, the sensor device 300 may send sensor glucose values that have been obtained and collected during the last 15 minutes, for purposes of redundancy or error checking.
The battery 342 may be a single-use (disposable) battery or a rechargeable battery. The battery 342 represents the main power source of the sensor device 300, and is suitably configured to provide operating power to the at least one processor 330, the memory 334, the wireless communication interface 338, the accelerometer 346, and other components (not shown) as needed. Accordingly, the battery 342 may provide a relatively low amount of operating power during a standby or dormant state, and an increased amount of operating power during an active or deployed state (e.g., in response to processor(s) detecting deployment based on output from accelerometer 346). For example, the battery 342 may provide sufficient power to the accelerometer 346 to support its operation during a standby or dormant state, such that the accelerometer 346 can respond to acceleration or movement of the sensor device 300, e.g., when the user is ready to deploy the sensor device 300 onto the body. Moreover, the wireless communication interface 338 can be held in a low power or “off” mode during the standby or dormant state, and switched to a high power or “on” mode for operation during the active state (e.g., after deployment).
The accelerometer 346 is configured, arranged, and operated to measure acceleration, motion, orientation, or handling of the host device, e.g., the sensor device 300. In certain embodiments, the accelerometer 346 is configured to generate a suitably formatted output (e.g., a signal, a voltage level, an acceleration measurement or reading, a wakeup signal, a flag, a logical state, or the like) in response to detecting acceleration of the sensor device 300. Alternatively or additionally, the accelerometer 346 can be polled by the at least one processor 330 to obtain acceleration readings on demand, as needed, according to a designated schedule, periodically, etc. Other methodologies for detecting or measuring acceleration may be employed by embodiments of the host device. The accelerometer 346 can be implemented using any type of commercially available or custom accelerometer device, circuit, or package.
When the sensor device 300 or the accelerometer 346 is enabled or in the active state, the sensor device 300 may communicate the accelerometer output to a destination device (such as a remote processing device or system or a user device) more often than the sensor glucose values. Indeed, the accelerometer output should be communicated and handled at a high sampling rate to enable the system to quickly detect and respond to motion, movement, and acceleration of the sensor device 300 in real time or substantially real time. To this end, accelerometer output may be communicated every second, every 500 milliseconds, or the like. In accordance with certain embodiments, the accelerometer data (3-axes) is collected at a frequency of 200 Hz, and at a resolution of 12 bits. When streaming accelerometer data to a mobile device, a BLUETOOTH wireless link changes to a high throughput configuration to accommodate 1,400 byes per second. For this implementation, the latency from collection to transmission is less than 500 milliseconds. This accelerometer data stream can be compressed to 900 bytes per second (or less), depending on the particular embodiment.
The at least one processor 330 controls certain operations of the sensor device 300. In particular, the at least one processor 330 is configured and arranged to receive the output generated by the accelerometer 346, process the output, and initiate communication of the output (as needed) to one or more other components of the system 100. For example, the output of the accelerometer 346 can be wirelessly transmitted to the user device 106 for processing and handling as described in more detail below.
In certain embodiments, the accelerometer 346 can be operated in a low power mode (e.g., a wake-on-motion mode) and a normal power mode. For example, the accelerometer 346 may be held in the low power mode (to conserve battery power) until the user activates the sensor device 300 or until a threshold amount of motion or acceleration is detected. The processor(s) 330 may also be placed into a low-power mode to conserve power. When motion or a certain motion pattern is detected, the accelerometer 346 and/or the processor 330 may switch into a higher power mode. Conversely, the accelerometer 346 can be disabled or returned to its low power mode after deployment of the sensor device 300.
The user-mountable electronic devices shown in
In accordance with certain embodiments, any or all of the components shown in
The illustrated embodiment of the device 600 depicted in
The at least one controller 602 may be implemented or performed with a general purpose processor, a content addressable memory, a microcontroller unit, a digital signal processor, an application specific integrated circuit, a field programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination designed to perform the functions described here. Moreover, the at least one controller 602 may be implemented as a combination of computing devices, e.g., a combination of a digital signal processor and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a digital signal processor core, or any other such configuration.
The memory 604 may be realized as at least one memory element, device, or unit, such as: RAM memory, flash memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. In this regard, the memory 604 can be coupled to the at least one controller 602 such that the at least one controller 602 can read information from, and write information to, the memory 604. In the alternative, the memory 604 may be integral to the at least one controller 602. As an example, the at least one controller 602 and the memory 604 may reside in an ASIC. At least a portion of the memory 604 can be realized as a computer storage medium that is operatively associated with the at least one controller 602, e.g., a tangible, non-transitory computer-readable medium having computer-executable instructions stored thereon. The computer-executable instructions are configurable to be executed by the at least one controller 602 to cause the at least one controller 602 to perform certain tasks, operations, functions, and processes that are specific to the particular embodiment. In this regard, the memory 604 may represent one suitable implementation of such computer-readable media. Alternatively or additionally, the device 600 could receive and cooperate with computer-readable media (not separately shown) that is realized as a portable or mobile component or platform, e.g., a portable hard drive, a USB flash drive, an optical disc, or the like.
The device-specific items 606 may vary from one embodiment of the device 600 to another. For example, the device-specific items 606 will support: sensor device operations when the device 600 is realized as a sensor device; smartphone features and functionality when the device 600 is realized as a smartphone; activity tracker features and functionality when the device 600 is realized as an activity tracker; smart watch features and functionality when the device 600 is realized as a smart watch; medical device features and functionality when the device is realized as a medical device; etc. In certain cases, the device-specific items 606 includes the at least one sensor device 104 (see
If present, the UI of the device 600 may include or cooperate with various features to allow a user to interact with the device 600. Accordingly, the UI may include various human-to-machine interfaces, e.g., a keypad, keys, a keyboard, buttons, switches, knobs, a touchpad, a joystick, a pointing device, a virtual writing tablet, a touch screen, a microphone, or any device, component, or function that enables the user to select options, input information, or otherwise control the operation of the device 600. The UI may include one or more graphical user interface (GUI) control elements that enable a user to manipulate or otherwise interact with an application via the output interface 614. The output interface 614 and/or the device-specific items 606 may be utilized to generate, present, render, output, and/or annunciate alerts, alarms, messages, or notifications that are associated with operation of the system 100, associated with a status or condition of the user, associated with operation, status, or condition of the system 100, etc.
The communication interface 610 facilitates data communication between the device 600 and other components as needed during the operation of the device 600. In the context of this description, the communication interface 610 can be employed to transmit or stream device-related control data, patient-related user status, device-related status or operational data, sensor data, accelerometer data, calibration data, and the like. It should be appreciated that the particular configuration and functionality of the communication interface 610 can vary depending on the hardware platform and specific implementation of the device 600. In practice, an embodiment of the device 600 may support wireless data communication and/or wired data communication, using various data communication protocols. For example, the communication interface 610 could support one or more wireless data communication protocols, techniques, or methodologies, including, without limitation: RF; IrDA (infrared); Bluetooth; BLE; ZigBee (and other variants of the IEEE 802.15 protocol); IEEE 802.11 (any variation); IEEE 802.16 (WiMAX or any other variation); Direct Sequence Spread Spectrum; Frequency Hopping Spread Spectrum; cellular/wireless/cordless telecommunication protocols; wireless home network communication protocols; paging network protocols; magnetic induction; satellite data communication protocols; wireless hospital or health care facility network protocols such as those operating in the WMTS bands; GPRS; and proprietary wireless data communication protocols such as variants of Wireless USB. Moreover, the communication interface 610 could support one or more wired/cabled data communication protocols, including, without limitation: Ethernet; powerline; home network communication protocols; USB; IEEE 1394 (Firewire); hospital network communication protocols; and proprietary data communication protocols.
The at least one API 612 supports communication and interactions between software applications and logical components that are associated with operation of the device 600. For example, one or more APIs 612 may be configured to facilitate compatible communication and cooperation with the patient care application 108, and to facilitate receipt and processing of data from sources external to the device 600 (e.g., databases or remote devices and systems).
The output interface 614 is suitably configured to enable the device 600 to render and display various screens, recommendation messages, alerts, alarms, notifications, GUIs, GUI control elements, drop down menus, auto-fill fields, text entry fields, message fields, or the like. Of course, the output interface 614 may also be utilized for the display of other information during the operation of the device 600, as is well understood. Notably, the specific configuration, operating characteristics, size, resolution, and functionality of a display element can vary depending upon the implementation of the device 600.
The process 700 may begin in response to an initialization, startup, or triggering event. In this regard, the process 700 may obtain an initialization signal, output, or message indicating that the user intends to deploy a user-mountable electronic device (task 702). The initialization signal, output, or message may be user-initiated at a device within the system environment. Alternatively or additionally, the initialization signal, output, or message may be automatically generated and provided in response to detection of a particular event, condition, or status of the user-mountable electronic device. For example, the accelerometer or another sensor device onboard the user-mountable electronic device may generate output that indicates the user is handling, moving, or otherwise preparing the user-mountable electronic device for deployment onto the body.
This description assumes that an obtained deployment initialization signal, output, or message triggers the remainder of the process 700. Accordingly, the process 700 may proceed by receiving sensor output generated by at least one sensor device onboard the user-mountable electronic device (task 704). For this example, the at least one sensor device is an accelerometer device, and the received sensor output is the data or output provided by the accelerometer device, but the at least one sensor device may be any motion sensor as described above. The received sensor output is processed to identify a body part on which the user intends to deploy the user-mountable electronic device (task 706). In certain embodiments, received accelerometer data can be analyzed and compared (in real-time or substantially real-time) to historical device deployment data to determine whether the user-mountable electronic device is being held, positioned, moved, adjusted, and/or located in a manner that corresponds to a known body part. Alternatively or additionally, the process 700 may consider additional information or data from other sources when identifying the body part for deployment. For example, the user may identify the body part by interacting with the user device, the user-mountable electronic device, a web page, or the like. As another example, audio, image, and/or video data (captured while the user is handling the user-mountable electronic device) may be considered to determine the body part.
In certain embodiments, the received accelerometer data need not be analyzed or processed in real-time or substantially real-time. Instead, the received accelerometer data can be collected for post-processing or post-analysis, for purposes of informing subsequent device deployment operations. For example, received accelerometer data can be collected as a way to automatically log or record different wear locations for a user, such that historical wear locations can be identified for future reference or deployment guidance. In such an example, process 700 may begin at task 704 or 706.
In accordance with some examples, the process 700 can determine one or more alternative body parts (other than the body part identified at task 706), recommend the one or more alternative body parts for deployment, and cause an output interface to provide guidance to deploy the user-mountable electronic device on the one or more alternative body parts (task 708). An alternative body part can be recommended based on historical outcomes data for medical devices that have been deployed on particular body parts. The historical outcomes data may include outcomes data for the user and/or outcomes data associated with a population of users (i.e., data for at least one person other than the user). For example, the process 700 may suggest deployment of the device on the right thigh instead of the left upper arm, based on collected patient data that indicates better therapy outcomes when the device is located on the right thigh.
The following description assumes that the user will deploy the device on the body part identified at task 706. The process 700 continues by determining at least one preferred orientation of the user-mountable electronic device relative to the identified body part (task 710). Device orientation can be detected and recorded based on real-time (or substantially real-time) accelerometer data. In this regard, device orientation may be determined relative to a gravity vector as measured or observed based on the accelerometer data. Preferred device orientations for different body parts can be maintained in an appropriate database, e.g., the database(s) 114 (see
The process 700 may continue by causing an output interface to generate and provide deployment guidance that indicates the preferred orientation of the user-mountable electronic device (task 712). In accordance with certain implementations, the output interface includes a display element of a user device, and the process 700 causes the display device to display instructions regarding how to position the user-mountable electronic device on the identified body part prior to deployment (task 714). As another example, the process 700 causes the display device to display at least one image, at least one video clip, or animated content that shows how to position the user-mountable electronic device on the identified body part prior to deployment (task 714). In accordance with certain embodiments, post-deployment data is collected over a period of time to record historical deployment locations (body parts) and/or historical device orientations, and the process 700 causes the display device to display a picture or a diagram of a body or a body part with markers or indicators corresponding to previous device deployment locations and/or orientations. Video or image content may be in the form of saved tutorials, or it can include augmented reality features that leverage the camera functions of a user device and/or the accelerometer output as generated during the device deployment routine.
In certain scenarios, the process 700 need not identify a preferred device deployment orientation. For example, if the system does not have sufficient historical outcomes data to recommend a specific device orientation, then the process 700 may simply provide general guidance or instructions for deploying the user-mountable device onto an identified body part. As another example, the system may have enough historical outcomes data to determine that device orientation has little to no impact on the patient outcome. Accordingly, the process 700 may provide general guidance or deployment instructions and/or indicate that the user is free to choose the device orientation.
In some examples, the process 700 assumes that the user-mountable device is successfully deployed onto the identified body part, and in a known orientation that can be recorded or otherwise documented. The user-mountable device is operated after deployment on the particular body part, and in the specific orientation relative to the particular body part (task 716). In other examples, the process 700 continues by collecting performance or outcome data for the user-mountable device following deployment on the particular body part (task 718). The performance or outcome data can originate from the user-mountable device itself, from a sensor or other component of the user-mountable device, from a related monitoring device or system, from a remote server device or system, from a user device, or the like. The collected performance or outcome data can be correlated with the particular body part and the specific device orientation, for archiving or for use during subsequent device deployments. In this regard, a suitably configured and formatted database, such as the database(s) 114 described above with reference to
In most situations, the at least one sensor device (e.g., an accelerometer device) is located within the housing of the user-mountable electronic device. Alternatively, the at least one sensor device can be located in the deployment mechanism (which is usually removed/discarded after it has been actuated to deploy the user-mountable device). The following description assumes that the at least one sensor device is located at the user-mountable electronic device, and that the at least one sensor device remains active and operational after deployment of the user-mountable electronic device. Consequently, the user-mountable electronic device can leverage the output of the at least one sensor device for other purposes and applications if so desired.
In accordance with one non-limiting example, after deployment of the user-mountable electronic device on the body of the user, the at least one sensor device generates sensor output in response to physical tapping, bumping, shock, or concussion on the housing of the device. The user-mountable electronic device processes this sensor output to detect at least one distinguishable tapping gesture, input, or pattern resulting from the user tapping on or otherwise interacting with the housing. If a known tapping action is detected, then the user-mountable electronic device can perform one or more operations or functions (as appropriately linked to the detected tapping action). If not, then the user-mountable electronic device can disregard or ignore the tapping action, and need not respond to the tapping action. In certain implementations, the user-mountable electronic device is configured to detect a plurality of different tapping patterns corresponding to a plurality of different operations, functions, or processes performed by the user-mountable electronic device. Moreover, at least some of the plurality of different tapping patterns can be user-configurable, such that the user can program or train the user-mountable electronic device to react to customized user-designated tapping inputs (e.g., tap patterns or combinations).
Any number of device features, functions, or operations can be controlled by tapping actions detected by processing the sensor output. In accordance with some exemplary embodiments where the user-mountable device is a continuous glucose monitor device, some or all of the following operations can be linked to corresponding tapping actions (e.g., tap patterns or combinations): activate device; deactivate device; wireless pairing with another device; re-initiate wireless connection with another device; enable communication from the user-mountable device to a third party device or system (e.g., a caregiver system); control setup or initialization of a newly deployed user-mountable device (e.g., a replacement continuous glucose monitor device); meal announcements; silence, mute, or snooze an alert or alarm or notification; power management; detect removal or loss of the user-mountable electronic device; detect injury to the user (e.g., falling down, accidents, physical shock or impact); detect impact or damage to the user-mountable electronic device; user activity/sleep detection and characterization; detect user body or limb movements and gestures; detect meal consumption; detect or measure respiratory rate.
The specific types and number of operations and functions linked to tapping actions may vary from one embodiment to another, and will be appropriate to the particular type of user-mounted electronic device. The examples provided above are contextually relevant where the device is a continuous glucose monitor. Additional, alternative, and different operations, features, and functions can be supported where the device something other than a continuous glucose monitor, e.g., a fluid infusion device, an activity monitor, or the like.
While at least one exemplary embodiment has been presented in the foregoing detailed description, it should be appreciated that a vast number of variations exist. It should also be appreciated that the exemplary embodiment or embodiments described herein are not intended to limit the scope, applicability, or configuration of the claimed subject matter in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient road map for implementing the described embodiment or embodiments. It should be understood that various changes can be made in the function and arrangement of elements without departing from the scope defined by the claims, which includes known equivalents and foreseeable equivalents at the time of filing this patent application.
