JP6931098B2 - Presentation of physiological data - Google Patents

Description

The following disclosures relate generally to data management and, more specifically, to aggregating and sharing health data.

Currently, about 133 million Americans suffer from at least one chronic illness. This number is expected to increase to about 165 million by 2020. As a result, the cost of health care in the United States is expected to increase dramatically. Attempts have been made to improve the health of each individual by providing tools for monitoring and tracking their own health data. Health data can typically include any type of data associated with human health, such as weight, heart rate, blood pressure, blood glucose, medication compliance, activity levels, etc. Users can monitor their health using devices such as sphygmomanometer cuffs, blood glucose monitors, electrocardiograms, and step counters. Software applications (eg, apps) associated with each of these devices have also been developed to allow users to track their health data over time. Each application can be used to display useful information about a user's health, but current applications have the ability to allow users to store, view, and share health data collected by different devices. Is restricted.

The present disclosure relates to processing for aggregating and sharing health data. One exemplary process is to display an aggregated view of multiple types of health data, the aggregated view containing multiple partitions, and each partition of the plurality of partitions is of multiple types. Being associated with one type of health data, receiving a selection of one of multiple parcels, and displaying an expanded view of the selected parcel of multiple parcels. It may include that.

In one embodiment, in an aggregated view, each parcel of a plurality of parcels contains an identifier for the associated type of health data and a first portion of the associated type of health data displayed with it. The expanded view includes a larger view of the selected parcel of the parcels, and a second portion of the associated type of health data displayed with it. In another embodiment, the first part of the health data contains the latest values of the associated type of health data and the second part of the associated type of health data contains the associated type of health data. Including the time-lapse expression of.

In one embodiment, displaying an expanded view of a selected parcel comprises displaying a collapsed set of parcels representing an unselected parcel of a plurality of parcels. In another embodiment, the parcels are ordered in the display based on the frequency of use of the associated type of health data, the time of the most recently added value of the associated type of health data, or the time of day. ..

In one embodiment, the expanded view of the selected parcel contains selectable elements for sharing the health data associated with the parcel via email or text message.

In one embodiment, the plurality of types of health data includes weight data, blood glucose data, blood pressure data, activity data, or heart rate data. In another embodiment, at least one of the plurality of types of health data is generated from sensor data acquired from the plurality of sensors.

In one embodiment, the expanded view contains a graph of associated types of health data, and the graph contains segments generated from health data obtained from various sensors.

In one embodiment, one of the plurality of compartments is a user-generated compartment. In another embodiment, the compartments have the appearance of a stack of cards displayed in a stack.

Another exemplary process is to display multiple parcels on the device, where each parcel of the parcels is associated with one type of health data of the plurality of types of health data. And to select a subset of multiple partitions and to display the selected subset of multiple partitions, depending on the detection of a change in device orientation.

In one embodiment, changes in device orientation are detected based on data from the device gyroscope, device accelerometer, or at least one combination thereof. In another embodiment, detecting a change in device orientation comprises detecting a threshold amount of change in device orientation.

In one embodiment, each of the displayed subsets of the plurality of compartments comprises a graphical representation of at least a portion of the associated type of health data displayed with it. In another embodiment, selecting a subset of multiple compartments identifies correlations between multiple types of health data and multiple compartments associated with the types of health data that correlate. Includes selecting as a subset of.

Another exemplary process is to display the first plurality of partitions associated with the first user, where each partition of the first plurality of partitions is one type of first user. A second plurality associated with a second user, in response to being associated with the health data of the second user and receiving a request to view the second plurality of compartments associated with the second user. Each section of the second plurality of sections may be associated with one type of health data of the second user.

In one embodiment, the request for viewing the second plurality of sections includes a request for laterally scrolling the displayed first plurality of sections. In another embodiment, the request to browse the second plurality of compartments includes selecting a second user from the list of users.

In one embodiment, the first user is authorized by the second user to browse the second plurality of compartments.

Another exemplary process is to receive the identifier of a user authorized to access a set of health data and to access the set of health data in response to detecting an update to the set of health data. Send a notification to authorized users to inform authorized users that an update to a set of health data has been detected to access the set of health data, and at least one of the sets of health data. The unit may include sending the part to an authorized user to access a set of health data.

In one embodiment, the identifier of a user authorized to access a set of health data includes name, username, or contact information. In another embodiment, at least a portion of the health data set is transmitted in response to receiving a request from a user authorized to access the health data set.

Another exemplary process is receiving a request from the first user to access the health data associated with the second user and the first user with the health data associated with the second user. Sends a request to the second user to authorize access to, and in response to receiving authorization from the second user, the health data associated with the second user is sent to the first user. It may include sending to the user.

In one embodiment, the first user is a health care provider, the second user is a patient, and the requirements to access the health data associated with the second user are the first user and the first. Received before the meeting with 2 users. In another embodiment, the request for authorizing the first user to access the health data associated with the second user is displayed on the second user's mobile device.

Systems and non-temporary computer-readable storage media for performing these processes are also provided.

FIG. 6 is a block diagram of an exemplary system for aggregating health data for various embodiments.

It is a block diagram of an exemplary system for sharing health data, according to various embodiments.

FIG. 5 illustrates an exemplary process for performing authorization and pushing health data to other authorized users, according to various embodiments.

FIG. 5 illustrates exemplary processing for authorizing a user to pull health data, according to various embodiments.

FIG. 5 illustrates an exemplary interface for displaying aggregated health data for various embodiments. FIG. 5 illustrates an exemplary interface for displaying aggregated health data for various embodiments. FIG. 5 illustrates an exemplary interface for displaying aggregated health data for various embodiments. FIG. 5 illustrates an exemplary interface for displaying aggregated health data for various embodiments. FIG. 5 illustrates an exemplary interface for displaying aggregated health data for various embodiments. FIG. 5 illustrates an exemplary interface for displaying aggregated health data for various embodiments.

It is a figure which shows the exemplary process for displaying the aggregated health data which concerns on various examples.

FIG. 5 illustrates an exemplary interface for displaying aggregated health data for various embodiments.

It is a figure which shows the exemplary process for displaying the aggregated health data which concerns on various examples.

FIG. 5 illustrates an exemplary interface for displaying aggregated health data of other users, according to various embodiments.

FIG. 5 illustrates another exemplary interface for displaying aggregated health data of other users, according to various embodiments.

It is a figure which shows the exemplary process for displaying the aggregated health data of another user which concerns on various examples.

FIG. 5 illustrates an exemplary computer system for aggregating and sharing health data, according to various embodiments.

In the following disclosures and description of examples, reference is made to the accompanying drawings in which specific examples that can be performed are illustrated. It should be understood that other examples can be implemented and structural changes can be made without departing from the scope of this disclosure.

This disclosure relates to aggregating and sharing health data. Health data may be received by the user device from any number of sensors outside or inside the user device, from the user who manually inputs the health data, or from other users or entities. The user device may transmit the health data to be securely stored in the user device and the health data to be stored in the remote database. The user of the device may share some or all of the health data with friends, relatives, caregivers, health care providers, and the like. The user device may further display the user's health data in an aggregated view of various types of health data. For example, the aggregated view may include a set of compartments, where each compartment corresponds to a different type of health data. If authorization is received from those users, the health data of other users can also be viewed. In some embodiments, parcels may be displayed as having the appearance of stacked cards and associated animations, with each parcel corresponding to a different parcel (and hence different types of health data). .. In this stacked card view, each card may display a partial view of a portion of the corresponding health data. When the user selects one of the cards, the first of the selected cards, including at least one of the first reconstructed data, additional data, or an expanded view of the original data. The expanded view of 1 may be displayed. A second expanded view of the selected card may be displayed as the orientation of the user device changes. The second expanded view may include at least one of the expanded views of the second reconstructed data, additional data, or original data. In one embodiment, the second expanded view may include a time-lapse graph of health data.
System overview

FIG. 1A shows an exemplary system 100A for aggregating and sharing health data. As mentioned above, health data may include, but is not limited to, any kind of data associated with human health such as weight, heart rate, blood pressure, blood glucose, medication compliance, activity level and the like. System 100A collects health data associated with the user, stores the health data, provides the health data in a useful manner to the user, and distributes the user's health data with other users or entities based on the user's permission set. It may be used for selective sharing. Further, in some embodiments, the system 100A may be further used to collect non-health data with health data, associate non-health data with health data, and display non-health data with health data.

System 100A may include one or more user devices 110 including any electronic device such as a mobile phone, tablet computer, desktop computer, laptop computer, PDA and the like. The user device 110 may include an operating system and may include healthy or unhealthy data such as when the data was recorded, the type of data, the device used to record the data, the user associated with the data, and the like. It may include a health database 111 for secure storage with associated metadata. The user device 110 may further include an application programming interface (API) with access control for storing the data in the health database 111 and for accessing the data stored in the health database 111. ..

The user device 110 may be configured to receive health or non-health data from various sources and store the received data in the health database 111. For example, the user device 110 may be configured to receive healthy or unhealthy data from sensors 102, 104, 106, and 108. These sensors may include any type of sensor capable of acquiring health data, such as biosensors, activity tracking devices, and the like. For example, sensors 102, 104, 106, and 108 include, but are not limited to, a weight scale, a blood pressure monitor cuff, a blood glucose monitor, an electrocardiogram, a step counter, a gyroscope, an accelerometer, a SpO2 sensor, a respiratory sensor, a posture sensor, and the like. It may include a stress sensor, a photoelectric fingertip volume pulse wave, a galvanic skin reaction sensor, a temperature sensor, an asthma inhaler and the like. Sensors 102, 104, 106, and 108 are audio sensors, ambient light sensors, electromagnetic sensors, touch sensors for acquiring non-health data such as status data, time data, personal data, contact data, and similar data. , Other types of sensors such as capacitive sensors may also be included. In some embodiments, each sensor may be a separate device, but in other embodiments, any combination of two or more of the sensors may be included within a single device. For example, a gyroscope, accelerometer, photoelectric fingertip volume pulse wave, galvanic skin reaction sensor, and temperature sensor may be included in a wearable electronic device such as a smartwatch, but a weight scale, blood pressure monitor cuff, etc. The blood glucose monitor, SpO2 sensor, respiratory sensor, posture sensor, stress sensor, and asthma inhaler may be separate devices. Specific examples are provided, but it should be understood that other sensors may be used and other combinations of sensors may be combined into a single device.

Sensors 102, 104, 106, and 108 may be used to measure health or non-health data continuously, intermittently, periodically, or at any other desired frequency or time interval. .. For example, sensors 102, 104, 106, and 108 may be used to acquire a single measurement or multiple measurements over a length of time. Sensors 102, 104, 106, and 108 may be configured to measure healthy or unhealthy data at the same time interval, or may be configured to measure healthy or unhealthy data at different time intervals. good. These intervals may be set by the user or may be the default settings for each sensor. In addition, sensors 102, 104, 106, 108 may be used to measure health or non-health data at any time or place desired by the user. In addition, sensors 102, 104, 106, and 108 may be used with or without supervision of a health care provider. For example, the user may use sensors 102, 104, 106, and 108 to obtain sensor measurements at home without the supervision of a medical professional.

In some embodiments, the user device 110 is associated with sensors 102, 104, 106, and 108, respectively, to connect with the sensor and allow the user device 110 to receive healthy or unhealthy data. The software sensor application 113 (eg, a third party application) may be included. In these embodiments, application 113 may use the device API to store health or non-health data in the health database 111 of the user device 110. In some embodiments, the software sensor application 113 may be an application and the device 110 may be a smartphone, tablet computer, or the like. It should be understood that a "third party" may correspond to an entity different from the entity that created and / or maintained the manufacturer of device 110 and / or the operating system of device 110. In these cases, third-party applications and their corresponding sensors can communicate and function within the operating system of device 110 according to the default device protocol associated with device 110.

Application 113 may likewise use the device API to access the data stored in the health database 111. In another embodiment, the user device 110 has one or more communication formats, sensors 102, 104, 106, to allow the user device 110 to receive and interpret healthy or unhealthy data from the sensor. And 108 may be configured to be shared. The received data may then be stored in the health database 111 of the user device 110.

The user device 110 can be from its own health or non-health data sensor 115 such as a GPS sensor, clock, gyroscope, accelerometer, from a user interacting with the user device 110, from another entity such as a doctor, or from another non-health. Further health or non-health data may be received from the sensor source. For example, even if health or non-health data is received from application 117 on user device 110, such as clock application, calendar application, gaming application, application from health care provider, messaging application, etc. using the device API. good. Health or non-health data from application 117 is from users interacting with the application, remote databases (eg, medical website databases), health care providers (eg, via institutional apps), and so on. May be good. In these examples, application 117 usage (eg, how long the video game application was played, when the video game was played, how many times the stock application was interacted with, how many times the social networking application was interacted with, the social networking application The length of time interacted with the user device 110 (eg, the length of talk time determined by the phone payment application or the number of text messages sent, browsing the Internet as determined by the device's browser). Time, etc.), time to watch music as determined by the music or streaming radio application, time to use the remote application to control the TV, amount of time and money spent on shopping websites, spending on adult websites Time spent (eg, to identify addiction), meteorological data from a meteorological application (eg, to determine how the weather affects a user's health), and the user's life as determined by a calendar. With specific people determined from the type of event that occurs within (eg, meeting people, birthdays, holidays, etc.), contact list and / or calendar application and / or messaging application and / or user device 110 phone. The exchange and the like may be received by the user device 110 and stored in the health database 111.

In some embodiments, at least one application on the user device 110 (eg, at least one of applications 113 and 117) is the health database 111 of the user device 110 (for both storage and retrieval purposes). To, and to limit access to the sensor data generated by the sensor 115 in the user device 110 and / or the sensor data generated by the sensors 102, 104, 106, and 108, the default or user. The settings selected by may be provided. For example, an application for tracking a user's running session may be authorized to access the data generated by the GPS sensor on the user device 110, but the user's blood pressure data stored in the health database 111 may. It may be made inaccessible. In some embodiments, an entity other than the owner of the user device 110 may set authorization settings for various applications on the user device 110. For example, the manufacturer of the user device 110 and / or the entity that created and / or maintained the operating system of the user device 110 evaluates the application and they generate or receive the user's health data and / or the user device 110. You may decide whether to grant access to the sensor data. In some embodiments, these settings may be overridden by the user.

The user device 110 may further include a display for displaying stored health or non-health data. A more detailed description of the display interface of the user device 110 will be described below in connection with FIGS. 6-17.

FIG. 1B shows a system 100B for sharing user health data. With reference to FIG. 1B, the user server 114 is communicably coupled to the user device 110 via the Internet, an intranet, or a network 112 that may include any other wired or wireless public or private network. The user device 110 is configured to securely transmit aggregated health or non-health data and associated metadata stored on the device to the user server 114 for storage in the user database 116. You may. In some embodiments, the healthy or unhealthy data and associated metadata are stored in the user database 116 in response to an explicit request for such transfer by the user of device 110. May be sent to the user server 114, but in other embodiments, healthy or unhealthy data is continuously, cyclically, intermittently, or at any desired frequency in the user database 116. It may be synchronized with the data. In yet another embodiment, the user's health or non-health data may be stored only on the user device 110 or not in an external database.

In some embodiments, the user server 114 and the user database 116 use a public / private key system that allows only the owner of healthy or unhealthy data to decrypt the data, and the user's healthy or unhealthy data. It may be configured to store health data securely. In addition, the health or non-health data stored in the user database 116 is stored anonymously (eg, without identification and / or personal information about the user (such as real name, username, time and location data)). May be good. In this way, other users, hackers, and owners / operators of the user database 116 cannot determine the identity of the user associated with the data stored in the database 116. In some embodiments, the user migrates to his or her health or unhealth data stored in the user database 116 from a different user device than that used to upload the health or unhealth data to the user server 114. Can be accessed. In these cases, the user may be required to provide login credentials in order to access his or her health or non-health data. The user server 114 may be configured to perform an authorization process to limit access to data in the user database 116.

System 100B may further include any number of other user devices 122 and 124 coupled to network 112. In some embodiments, the user devices 122 and 124 may be operated by the same user as the user device 110. In these cases, the user can access his or her health or non-health data stored in the user database 116 by providing the user server 114 with the appropriate credentials. In some embodiments, health and non-health data may be synchronized between the user database 116 and one or more of the user devices 110, 122, and 124. In another embodiment, the users of user devices 122 and 124 may be different from the users of user device 110. In these embodiments, the users of devices 122 and 124 cannot access the health or unhealthy data of the user of user device 110 without the authorization of the user of user device 110. Once licensed, health or non-health data can be shared with users on user devices 122 and 124. This data sharing will be described in more detail below in connection with FIGS. 4-5.

In some embodiments, any of the sources of health or non-health data described above is healthy, intermittently, intermittently, periodically, or at any other desired frequency or time interval. Alternatively, it may be configured to measure, generate, or receive non-health data. Thus, health or non-health data is also stored or updated in the health database 111 or user database 116 continuously, intermittently, periodically, or at any other desired frequency or time interval. You may. The frequency and time interval used to measure, generate, receive, or store healthy or unhealthy conditions may be the same or different. In addition, these frequencies and intervals may be default values, or they are set by the user to provide the user with updated health or non-health data during the desired length of time. May be good.

Although not shown, many other user devices may be coupled to the user server 114 over the network 112 to collect and store health or non-health data of other users in a manner similar to that described above. Please understand that it is good.
User database

As mentioned above, the user's health or non-health data may be stored in the user database 116 and may be shared with other users with the authorization of the owning user. Other users may be any type of user, such as friends, family, caregivers, doctors, social media providers, and so on. Approval of various types and levels may be granted to health or non-health data stored in health database 116.

In some embodiments, the shared health or non-health data may be pushed to the user device of another authorized user (eg, user device 122 or 124). FIG. 2 shows an exemplary process 200 for performing authorization and pushing healthy or unhealthy data to other authorized users. At block 202, identifiers of other authorized users may be received. It may be received by a user device (eg, user device 110) from a user associated with shared health or non-health data. An identifier can be a username, real name, contact information, or any other identifier or credential to another user, along with the level of access, such as access to all of the healthy or unhealthy data or a subset of the healthy or unhealthy data. It may be included. In some embodiments, other authorized users may be grouped into user categories (eg, family, friends, other people, etc.), and each category may be grouped into those other authorized users. Associated with a particular set of health data types that the user is allowed to view. For example, users in the family category may be allowed to view all types of health data, and users in the friend category may only view activity data.

At block 204, the user's health or non-health data may be monitored by the user's device to determine if any updates have been made to the data. If the update has not been made, the process may repeat block 204. However, if additions or changes to the user's health or non-health data are identified, processing may proceed to block 206. In some embodiments, any change to the user's health or non-health data advances process 200 to block 206, but in other embodiments, only changes to the health or non-health data of a particular type of user. However, the process 200 is advanced to the block 206.

At block 206, the notification may be sent to one or more authorized other users. For example, the notification may be sent from the user's device (eg, user device 110) to another authorized user's device (eg, user device 122 or 124). The notification may include a message indicating that an update has been made to the user's health or non-health data. The process may then proceed to block 208.

At block 208, updated health or non-health data may be transmitted to other authorized users. For example, updated health or non-health data may be transmitted from the user's device (eg, user device 110) to another authorized user's device (eg, user device 122 or 124). In some embodiments, this data may only be transmitted if other authorized users indicate that they wish to view the updated health or non-health data, in other embodiments. The updated health or non-health data may be sent to the user device of the other authorized user without receiving a request to view the data from the other authorized user.

The push of health or non-health data performed using process 200 is in situations where the user wishes to continue to provide his or her up-to-date health or non-health data to the caregiver or family (or other user). May be useful. For example, by granting authorization for older parents to push their health or non-health data to their children, children constantly request this information from their parents for the health status or medication compliance of older users. It can be made possible to easily monitor without need.

In other embodiments, the user's health or non-health data may be shared with the other user by allowing the other user to pull the health or non-health data. FIG. 3 shows an exemplary process 300 for authorizing other users to pull healthy or unhealthy data. At block 302, a request to access health or non-health data for a particular user may be received. The request may identify the requested health or non-health data and, optionally, the user associated with some of the health or non-health data being accessed. The identifier may include a username, real name, contact information, or any other identifier or credentials for the user. The request may be received by the user's user device (eg, user device 110) associated with the requested data from the requesting user's user device (eg, user device 122 or 124).

At block 304, a request for authorization may be sent to the user associated with the requested health or non-health data. In some embodiments, the request is sent from the requesting user's user device (eg, user device 122 or 124) to the user's user device (eg, user device 110) associated with the requested data. May be good. The request may then be displayed to the user associated with the data requested by the user's device (eg, user device 110).

At block 306, it may be determined whether authorization has been received from the user associated with the requested health or non-health data. Authorization may be received in any form. For example, a prompt may be displayed on the user device 110 of the user associated with the requested data. If authorization is denied, processing may return to block 302. However, if authorization is granted, processing may proceed to block 308.

At block 308, the requested health or unhealthy data may be transmitted to the entity that requested access to the health or unhealth data at block 302. The requested health or non-health data may be transmitted from the user's device (eg, user device 110) to the device of the requesting entity (eg, user device 122 or 124).

In some embodiments, process 300 does not perform block 304 or 306 if authorization has been granted to access the user's health or non-health data before the request is made in block 302. , Block 302 may proceed to block 308. For example, if the parent grants the child access to his or her health or non-health data, block 302 may receive a request for the parent's health or non-health data by the child, and block 308 may request it. Health or non-health data may be sent to the child without any intervention by the parent.

Pulling health or non-health data using process 300 does not want other authorized users to be constantly provided with updates to the user's health or non-health data and provides occasional access to the data. Will be useful in the desired situation. For example, a physician may wish to access a patient's medical records and health or non-health data immediately prior to meeting the patient. In this situation, the physician may request the patient's health or non-health data and may receive the requested data or send the request to the patient's user device 110. Depending on the authorization received from the patient, the requested data may be transmitted from the user device 110 to the physician's computing device (eg, user device 122 or 124). In some embodiments, the received health or non-health data may be added to the electronic medical record (EMR) associated with the user.

In some embodiments, the user's health or non-health data cannot be permanently stored on the user device of another authorized user, regardless of whether the push or pull sharing model is used. In this way, authorization for these other users can be revoked, thereby preventing other previously authorized users from accessing the user's health data. In addition, in some embodiments, reports may be generated detailing or summarizing the user's health or non-health data. These reports may then be sent to any desired recipient via email, secure forwarding, and so on. In yet another embodiment, the user device 110 uses short-range communication or another communication protocol to transfer some or all of the user's health or non-health data such as medical insurance information, blood type, medical history, etc. It may be configured to communicate to healthcare professionals. This may be useful when checking in to a hospital or when relevant medical data is needed in a medical emergency.
Aggregated data view

As mentioned above, the user device 110 aggregates health or non-health data associated with the user received from the user from one or more sensors 102, 104, 106, and 108, or from sources other than the sensors. It may be configured as follows. The user device 110 may also be configured to display the user's aggregated health or non-health data in various ways using various interfaces.

FIG. 4 shows one exemplary interface 400 that can be used by the user device 110 to display the user's aggregated health or non-health data. Interface 400 may include any number of compartments 402, 404, 406, 408, 410, and 412, each containing different types of health data associated with the user. In the aggregated view of FIG. 4, parcels may be used to display a partial view of some of the various types of health data. In the embodiments shown in FIGS. 4-9, 11 and 13-14, parcels are illustrated as having the appearance of stacked cards and associated animations, with each card being a different parcel (and hence a different type). Health data). However, it should be understood that the compartments may be displayed in any other desired fashion.

The interface 400 may include a first compartment 402, which is displayed at the top of the interface and may contain a user's identifier (eg, a name). As shown, the user name "John Smith" of the user device 110 is displayed on the compartment 402. Interface 400 may further include a button 401 for viewing health data associated with other users. This feature will be described in more detail below in connection with FIGS. 14 and 15.

The interface 400 may further include another compartment 404 that is displayed adjacent to the compartment 402 so that it has an appearance that overlaps the compartment 402 like a stacked card. This compartment may include an indication of the type of health data contained on the compartment and a partial view of the health data of the compartment (eg, summary, example, etc.). Specifically, compartment 404 includes the word "weight" to indicate that the compartment contains weight data associated with the user "John Smith". Section 404 may further include the latest weight "185 lbs" of "John Smith".

The interface 400 may further include another compartment 406 that is displayed adjacent to the compartment 404 so that it has an appearance that overlaps the compartment 404 like a stacked card. This compartment may include an indication of the type of health data contained on the compartment and a partial view of the health data of the compartment (eg, summary, example, etc.). Specifically, compartment 406 includes the term "blood glucose" to indicate that the compartment contains blood glucose data associated with the user "John Smith". Section 406 may further comprise the latest blood glucose level "164 mg / dL" from "John Smith".

Interface 400 may further include another compartment 408 that is displayed adjacent to compartment 406 so that it has the appearance of overlapping compartment 406 like stacked cards. This compartment may include an indication of the type of health data contained on the compartment and a partial view of the health data of the compartment (eg, summary, example, etc.). Specifically, compartment 408 includes the term "blood pressure" to indicate that the compartment contains blood pressure data associated with the user "John Smith". Section 408 may further comprise the latest blood pressure measurement "117/67 mmHg" from "John Smith".

The interface 400 may further include another compartment 410 that is displayed adjacent to the compartment 408 so that it has an appearance that overlaps the compartment 408 like stacked cards. This compartment may include an indication of the type of health data contained on the compartment and a partial view of the health data of the compartment (eg, summary, example, etc.). Specifically, compartment 410 includes the word "activity" to indicate that the compartment contains activity data (eg, calories burned) associated with the user "John Smith". Section 410 may further include the latest "John Smith" calories burned "467 kcal" per day.

Interface 400 may further include another compartment 412 displayed adjacent to compartment 410 so that it has the appearance of overlapping compartment 410 like stacked cards. This compartment may include an indication of the type of health data contained on the compartment and a partial view of the health data of the compartment (eg, summary, example, etc.). Specifically, compartment 412 includes the word "heart rate" to indicate that the compartment contains heart rate data associated with the user "John Smith". Section 412 may further include the latest heart rate measurement "122 bpm" from "John Smith". Further, since the compartment 412 is at the top of the stacked compartments, additional information 414 and / or option 416 may be displayed on the surface of this compartment. In the illustrated embodiment, additional information includes the minimum, maximum, and resting heart rate of "John Smith" over a period of one week selected using option 416.

Some or all of the compartments may be static or dynamic. For example, the parcel 402 containing the user's name may remain at the top of the display, and the remaining parcels are associated with the time, how recently the health data associated with that parcel was updated, and that parcel. The health data may be ordered based on how often it is updated, whether important events (eg, taking medication, performing sensor measurements, etc.) are approaching. The ordering may be changed manually by the user. If interface 400 contains more compartments than can be displayed on a single screen, vertical scrolling may be performed to display the remaining compartments. Alternatively, a 3D scroll of parcels may be performed to provide the appearance of flipping stacked cards one after the other.

Although specific compartment types are provided above as an example, it should be understood that compartments containing various types of health data can be included within interface 400. In addition, the user may generate customized partitions that can be used to display any desired type of data entered by the user. For example, a compartment may be created to track a user's medication compliance. The user may enter the time, amount, and type of medication taken, and this data may be displayed on the parcel created. Other custom compartments for different types of health data such as nutrition, sleep, smoking may also be generated.

Further, although the above provided specific examples of some partial views of the parcel health data (eg, overviews, examples, etc.), the partial views summarize the health data examples in different ways. Or understand that it may be provided. For example, instead of displaying the most up-to-date values for a particular health data type, the average, mode, or median of health data over time (eg, week, month, year, etc.), in whole or in part. Another single data point, for example, may be displayed on a partition in the aggregated view. Alternatively, in other embodiments, the current and average values may be displayed on the parcels in the aggregated view. In yet another embodiment, the compartments in the aggregated view may include a display of current and target values for the type of health data.

Partitions 402, 404, 406, 408, 410, to display an expanded view of a partition, including reconstructed data, additional data, or an enlarged view of the original data contained on the partition. And 412 may be selected. For example, the user may select a parcel by tapping on the desired parcel displayed on the touch-sensitive display, or may use a mouse or other input device to highlight and click on the parcel. Alternatively, the desired compartment may be selected using any other input means. Depending on the partition selection, the user device 110 may hide the contents of the other partitions and display the selected partition on all or most of the display of the user device 110.

For example, FIG. 5 shows an exemplary interface 500 that may be displayed depending on the user selecting a partition 404 within the interface 400. At interface 500, the expanded view 405 of the compartment 404 may be prominently displayed in the display of the user device 110, with the remaining compartments appearing at the bottom of the display so that they disappear from the display. It may be animated as folded within a stacked compartment 502. In the illustrated embodiment, the expanded view 405 includes additional weight-related data not shown within the interface 400, such as the user's weight, body mass index (BMI), and fat percentage. It may be. The expanded view 405 further outlines the user's weight data, such as a sliding scale 540 showing the user's weight relative to the weight range and a graph 541 that tracks the user's weight on a daily, weekly, monthly, or yearly basis. It may be included. Interface 500 allows the user device 110 to display an option for sharing some or all of the user's health data using any desired communication medium such as text message, email, social media provider. The button 504, which can be used, may be further included. In these embodiments, the health data may be encrypted and transmitted directly from the user device 110 (rather than from the user server 114) to the recipient's user device, and the health data may be decrypted at the recipient's user device. To return to the aggregated view of partitions shown in interface 400, the user may select stacked partitions 502 (eg, tap, click, or otherwise select). It should be understood that the content of the interface 500 and the expanded view 405 is provided as an example, and the expanded view 405 may instead include any kind of weight-related data, or an overview of the weight-related data.

FIG. 6 shows an exemplary interface 600 that may be displayed depending on the user selecting compartment 406 within the interface 400. At interface 600, the expanded view 407 of compartment 406 may be prominently displayed in the display of user device 110, with the remaining compartments appearing at the bottom of the display so that they disappear from the display. It may be animated as folded within the stacked compartments 502. In the illustrated embodiment, the expanded view 407 may include additional blood glucose related data not shown within the interface 400, such as the user's blood glucose and units. Expanded view 407 includes a sliding scale 542 showing the user's postprandial blood glucose over a typical blood glucose range and a graph 543 that tracks the user's blood glucose on a daily, weekly, monthly, or yearly basis. A summary of blood glucose data may be further included. The interface 600 may also include the button 504 described above. To return to the aggregated view of partitions shown in interface 400, the user may select stacked partitions 502 (eg, tap, click, or otherwise select). It should be appreciated that the content of the interface 600 and the expanded view 407 is provided as an example, and the expanded view 407 may instead include any type of blood glucose-related data, or an overview of the blood glucose-related data.

FIG. 7 shows an exemplary interface 700 that may be displayed depending on the user selecting compartments 408 within interface 400. At interface 700, the expanded view 409 of compartment 408 may be prominently displayed in the display of user device 110, with the remaining compartments appearing at the bottom of the display so that they disappear from the display. It may be animated as folded within the stacked compartments 502. In the illustrated embodiment, the expanded view 409 may include additional blood pressure related data not shown within the interface 400, such as the user's blood pressure and beat per minute (bpm). The expanded view 409 is an overview of the user's blood pressure data, such as a sliding scale 544 showing the user's blood pressure relative to a typical blood pressure value and a graph 545 that tracks the user's blood pressure on a daily, weekly, monthly, or yearly basis. May be further included. The interface 700 may also include the button 504 described above. To return to the aggregated view of partitions shown in interface 400, the user may select stacked partitions 502 (eg, tap, click, or otherwise select). It should be appreciated that the content of the interface 700 and the expanded view 409 is provided as an example, and the expanded view 409 may instead include any kind of blood pressure-related data, or an overview of the blood pressure-related data.

FIG. 8 shows an exemplary interface 800 that may be displayed depending on the user selecting compartment 410 within the interface 400. In interface 800, the expanded view 411 of the compartment 410 may be prominently displayed in the display of the user device 110, with the remaining compartments appearing at the bottom of the display so that they disappear from the display. It may be animated as folded within the stacked compartments 502. In the illustrated embodiment, the expanded view 411 may include additional activity-related data not shown within interface 400, such as the user's calories burned, steps taken, distance traveled, and the like. Expanded view 411 shows the user's blood pressure, such as graph 546, which tracks the intensity of the user's activity on a daily, weekly, monthly, or yearly basis, and summary 547, which shows the total time spent on activity, rest, and exercise. Further summaries of the data may be included. The interface 800 may also include the button 504 described above. To return to the aggregated view of partitions shown in interface 400, the user may select stacked partitions 502 (eg, tap, click, or otherwise select). It should be understood that the contents of interface 800 and the expanded view 411 are provided as an example, and the expanded view 411 may instead include any kind of activity-related data, or an overview of the activity-related data.

FIG. 9 shows an exemplary interface 900 that may be displayed depending on the user selecting compartments 412 within interface 400. In interface 900, the expanded view 413 of the compartment 412 may be prominently displayed in the display of the user device 110, with the remaining compartments appearing at the bottom of the display so that they disappear from the display. It may be animated as folded within the stacked compartments 502. In the illustrated embodiment, the expanded view 413 may include additional heart rate related data such as the user's daily, weekly, monthly, or yearly minimum, maximum, and resting heart rate. However, unlike compartments 404, 406, 408, and 410, this data has already been displayed since compartment 412 was displayed in the aggregated view as being placed at the top of the stacked compartments. It was displayed in the interface 400. The expanded view 413 may further include an overview of the user's heart rate data, such as Graph 548, which tracks the user's heart rate on a daily, weekly, monthly, or yearly basis. The interface 900 may also include the button 504 described above. To return to the aggregated view of partitions shown in interface 400, the user may select stacked partitions 502 (eg, tap, click, or otherwise select). It is understood that the content of the interface 900 and the expanded view 413 is provided as an example, and the expanded view 413 may instead include any kind of heart rate related data, or an overview of the heart rate related data. sea bream.

In some embodiments, the user's health data used to generate the interfaces shown in FIGS. 4-9 may be received from one or more sensor devices and / or applications. In these examples, the same type of health data from different devices may be combined and displayed on a single compartment. For example, the weight data shown in interface 500 of FIG. 5 can be obtained from repeated measurements made using the same scale. Alternatively, some of the measurements may be taken from one scale and the remaining measurements may be taken from one or more different scales. As a result, some points in graph 541 may be generated using weight data from one scale, while other points in graph 541 are weights from one or more other scales. It may be generated using the data. In another embodiment, the activity data shown at interface 800 in FIG. 8 may be obtained from a single step counting device. Alternatively, the data is aggregated from a step counting device, a first GPS-enabled wristwatch used to record the user's running session, and a second GPS-enabled wristwatch used to record the user's rowing session. May be done. In these examples, the graph 546 showing the intensity of the user's activity is a segmented graph generated by combining data acquired from the step tracking device and the first and second GPS-enabled wristwatches. Often, each segment originates from one of the devices. In particular, graph 546 is from a first segment 550 generated from data from a step counting device, a second segment 552 generated from data from a first GPS-enabled wristwatch, and a second GPS-enabled wristwatch. A third segment 554 generated from the data may be included. Aggregating the data in this way is advantageous because the user can record and view the health data in a manner that does not directly link the health data to a particular device or application (eg, a smartphone application). Although three segments are shown in FIG. 8, it should be understood that the segmented graph can contain any number of segments corresponding to different sensors and / or applications.

FIG. 10 shows an exemplary process 1000 for displaying health data for various embodiments. In block 1002, an aggregated view of health data that includes multiple compartments similar to or identical to compartments 402, 404, 406, 408, 410, and 412 is similar or identical to user device 110. It may be displayed on the device. These compartments may include an identifier for the health data type displayed on the compartment and a partial view of some of the health data types associated with the compartment (eg, summary, example, etc.). For example, an interface similar to or identical to interface 400 may be displayed, including various health data compartments 402, 404, 406, 408, 410, and 412.

At block 1004, a selection of one of the displayed compartments may be received. This selection may be received by the user device or may be in the form of a mouse click, a tap on a touch-sensitive display, or the like. Block 1006 may display an expanded view of the selected compartment, depending on the compartment selection. The expanded view shows the larger portion of the selected parcel and the reconstructed health data (eg, the health displayed on the selected parcel in the aggregated view displayed in block 1002). A rearranged view of the data), additional health data (eg, health data that was not previously displayed on the selected parcel in the aggregated view displayed in block 1002), or displayed in block 1002. An enlarged view of the health data displayed in the aggregated view (eg, a larger view of the same health data displayed on the selected compartment in the aggregated view displayed in block 1002). It may include at least one of them. In addition, the size of the unselected compartments may be reduced or those compartments may be removed from the display. For example, depending on the choice of interface 400 compartments 404, 406, 408, 410, or 412, any of interfaces 500, 600, 700, 800, or 900 may be displayed, respectively.

In some embodiments, the display presented in block 1006 may include selectable options for sharing health data (eg, button 504). In another embodiment, the display presented in block 1006 may further include a selectable option (eg, partition 502) for redisplaying the aggregated view containing the partitions displayed in block 1002. .. The process may then return to block 1004, where selection of another partition may be received.

FIG. 11 shows an exemplary interface 1100 that may be displayed in response to the user rotating the user device 110 into landscape view. In this orientation, user device 110 may display an expanded view of a subset of partitions smaller than those displayed within the aggregated view of interface 400. For example, interface 1100 may include an expanded view 1102 in compartment 408, an expanded view 1104 in compartment 406, and an expanded view 1106 in compartment 412. In the illustrated embodiment, the expanded view of the parcel may include a graphical representation of health data over various lengths of time. This allows the user to view the displayed types of health data to see how they change with respect to each other over time, and changes in one type of health data to another type of health. You will be able to assess how it relates to changes in the data (or lack thereof). For example, one type of health data that can be displayed may include medications taken over time. This data may be compared to the user's blood pressure and heart rate to determine if the drug has beneficial or detrimental effects. In some embodiments, the user device 110 may select the type of health data that is displayed when the user device 110 is rotated in a landscape orientation. This selection may be based on a predetermined combination of types of health data that are often associated with each other, or may be based on an analysis of various types of health data. In the latter embodiment, the type of health data identified as potentially interrelated may be displayed. Types of health data that are not displayed in the initial display of interface 1100 can be displayed by scrolling through the compartment. In addition, partitions may be selected in the same way as performed on interface 400 to display more detailed information.

FIG. 12 shows an exemplary process 1200 for displaying health data based on device orientation, according to various embodiments. In block 1202, an aggregated view containing multiple partitions similar or identical to compartments 402, 404, 406, 408, 410, and 412 is displayed by a user device similar to or identical to user device 110. You may. These compartments may include an identifier for the health data type displayed on the compartment and a partial view of some of the health data types associated with the compartment (eg, summary, example, etc.). For example, an interface similar to or identical to interface 400 may be displayed, including various health data compartments 402, 404, 406, 408, 410, and 412.

At block 1204, a change in the orientation of the user device may be detected. For example, the gyroscope and / or accelerometer in the user device may indicate that the orientation of the device has changed from portrait to landscape. Processing may proceed to block 1206 depending on the detection of a change in orientation that reaches a threshold amount.

In block 1206, a subset of the plurality of partitions displayed in block 1202 may be selected for display. In some embodiments, the subset may be a predetermined subset of multiple compartments. In other embodiments, the subset may be selected based on user-defined display settings. In yet another embodiment, a subset of multiple compartments of the health data set associated with each compartment is used to determine if any of the types of health data may be correlated. It may be selected based on the analysis. If the potential for correlation is identified, block 1206 may select the compartments associated with the potentially correlated data.

Block 1208 may display an expanded view of a subset of the partitions selected in block 1206. In some embodiments, the identifier for the health data type displayed on the expanded view of the parcel and / or the summary, example, or other view of the health data type associated with the parcel is block 1202. It may be different from what is displayed on the partition with. For example, the data for each expanded view summary or example may be replaced with a graphical representation of the health data over time, as shown in FIG. This allows the relationship between the types of displayed health data to be observed. In some embodiments, processing may return to block 1202 in response to detecting that the orientation of the user device has been changed to portrait orientation.

As mentioned above, in some embodiments, the user of user device 110 may be authorized to access the health data of other users. In these embodiments, the user device 110 may allow the user to view the health data of another user in a format similar to that described above in connection with FIGS. 4-12. For example, as shown in interface 1300 of FIG. 13, the user scrolls the contents of the interface sideways in direction 1306 to view the health data of another user, and the first section from the first user. Set 1304 may be displayed in place of the second set 1302 of the parcel from the second user. In particular, a second set of compartments 1302 for a second user may be translated in the scroll direction 1306 so that they disappear from the display, and the first plurality of compartments 1304 may be in the same direction 1306 for the display. It may be translated from the other side onto the display. It should be appreciated that FIG. 13 shows a transition state in which compartment 1302 has been removed from the display and compartment 1304 is about to be scrolled onto the display in direction 1306. In this case, only the left side of compartment 1302 and the right side of compartment 1304 are displayed. As compartments 1302 and 1304 continue to scroll in direction 1306, a smaller portion of compartment 1302 is displayed until compartment 1302 is completely removed from the display and compartments 1304 occupy all or most of the display, in compartments 1304. Larger parts may be displayed. Although not shown, the top compartment of compartment 1304 may include the name of the first user and may be displayed as the screen continues to scroll in direction 1306. This scrolling operation may be performed any number of times (and in any direction) to scroll the entire partition for all users authorized to access by the user of device 110.

FIG. 14 shows another exemplary interface 1400 for displaying the health data of other users. In some embodiments, interface 1400 may be displayed, depending on the selection of button 401 on interface 400. As illustrated, interface 1400 may include lists 1402, 1404, 1406, and 1408 of users authorized to access their health data by users of user device 110. In some embodiments, the circle next to each user's name may be replaced with the image associated with the user. These images may be the same images used in the contact list of device 110, or may include different images. In the illustrated embodiment, users 1402, 1404, 1406, and 1408 are grouped into different categories (eg, self, family, and friends). These categories may be used to logically group users, or, as mentioned above, may indicate the level of authorization for displaying the health data of other users. For example, users in the "Family" category may authorize viewing a larger set of health data, and users in the "Friends" category authorize viewing a smaller set of health data. You may be doing it. Depending on the selection of one of the users 1402, 1404, 1406, and 1408, compartment 1410 may be updated to reflect the health data of the selected user. This is associated with updating the types of health data displayed on the parcels (eg, based on the types of health data that other users have authorized users of user device 110 to view). , May include updating some partial views of health data (eg, overview, examples, etc.). In another embodiment, the list of users 1402, 1404, 1406, and 1408 may be displayed in response to vertical scrolling of interface 400 up or down to display the list of users.

FIG. 15 shows an exemplary process 1500 for displaying health data associated with two or more users according to various embodiments. At block 1502, a display of the first plurality of partitions associated with the first user may be displayed. These compartments may be similar to or similar to compartments 402, 404, 406, 408, 410, and 412, and may be displayed by a user device similar to or identical to user device 110. These compartments may include an identifier for the health data type displayed on the compartment and a partial view of some of the health data types associated with the compartment (eg, summary, example, etc.). For example, an interface similar to or identical to interface 400 may be displayed, including various health data compartments 402, 404, 406, 408, 410, and 412.

At block 1504, a request to browse a second plurality of sections of a second user may be received. The second user may be a user who has authorized the first user to view his / her health data as described above. In some embodiments, the request may include user input for scrolling the display of the first plurality of compartments displayed in block 1502, such as mouse wheel rotation, arrow keys on the keyboard, touch-sensitive display. It may be received by the user device in the form of a touch and / or swipe of. Similar to the embodiment shown in FIG. 13, the scrolling direction may be horizontal to the content of the display and perpendicular to the scrolling direction to display the additional compartments associated with the first user. good. However, it should be understood that other scroll directions may be used. In another embodiment, the request to display the second plurality of partitions may be received in the form of a second user's selection from the list of users. For example, the second user may be selected from a list of users similar to those shown in FIG. This list is displayed according to the selection of a button (eg, button 401), or other selection mechanism such as vertical scrolling of a first plurality of compartments displayed in block 1502 to display a list of users. May be good. Processing may proceed to block 1506 in response to receiving a request to browse the second plurality of partitions in block 1504.

At block 1506, a display of the second plurality of partitions associated with the second user may be displayed. In some embodiments, if the request received at block 1504 for viewing the second parcels includes a request for scrolling the display of the first parcels, FIG. 13 As shown in, the first compartment may be translated in the scrolling direction so that it disappears from the display, and the second compartment may be translated in the same direction from the opposite side of the display onto the display. It may be translated. In another embodiment, if the request to view the second plurality of partitions received in block 1504 included the selection of a second user from the list of users, as shown in FIG. , The first plurality of compartments may be replaced with the display of the second plurality of compartments. To view the health data partitions of other users in order to view some or all of the set of partitions associated with the user authorized to view their health data by the user on device 110. Additional requests may be received and blocks 1504 and 1506 may be repeated.

It should be understood that the above processes may be combined. For example, the process 1200 may be combined with the process 1000 such that after the plurality of partitions are displayed in the block 1002, the blocks 1204, 1206, and 1208 are executed according to the change in the orientation of the user device. Similarly, after the plurality of partitions are displayed in block 1002, the process 1500 performs the plurality of partitions associated with another user in response to receiving a request for viewing the partition associated with another user. It may be combined with process 1000 such that blocks 1504 and 1506 are performed for display.

As mentioned above, the systems 100A and 100B measure, generate, receive, or store health or non-health data continuously, intermittently, periodically, or at any other desired frequency or time interval. It may be configured as follows. Similarly, processes 1000, 1200, and 1500 are performed to update the display of healthy or non-healthy data continuously, intermittently, periodically, or at any other desired frequency or time interval. You may. For example, a device performing processes 1000, 1200, or 1500 may continuously, intermittently, periodically, or any other desired the updated health or non-health data from the health database 111 or user database 116. It may be received at the frequency or time interval of. In some embodiments, the device performing processes 1000, 1200, or 1500 may receive updates for all healthy or unhealthy data at the same frequency or at time intervals. In another embodiment, the device performing processes 1000, 1200, or 1500 may be configured to receive updates to various types of data at different frequencies or at different time intervals. For example, heart rate data may be updated in seconds and weight data may be updated in days. These intervals and frequencies may be default values or may be selected by the user.

One or more of the functions relating to the aggregation and sharing of health data may be performed by a system similar to or identical to the system 1600 shown in FIG. The system 1600 may include instructions stored in a non-temporary computer-readable storage medium such as memory 1604 or storage device 1602 and executed by processor 1606. Instructions may also be an instruction execution system, device, or other system that fetches instructions from a computer-based system, a system that includes a processor, or an instruction execution system, device, or other system that can execute those instructions. It may be stored and / or transmitted to any non-temporary computer-readable storage medium for use by or with devices. In the context of this specification, a "non-temporary computer-readable storage medium" is any medium capable of accommodating or storing a program for use with or with an instruction execution system, device, or device. May be good. Non-temporary computer-readable storage media are, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or devices, portable computer disks (magnetic), random access memory, RAM. ), Read-only memory (ROM), electrically erasable programmable read-only memory (EPROM) (magnetic), CD, CD-R, CD-RW, DVD, It may include a portable optical disk such as a DVD-R or a DVD-RW, or a flash memory such as a compact flash® card, a secure digital card, a USB memory device, or a memory stick.

Instructions are also an instruction execution system, device, or other system that fetches instructions from a computer-based system, a system that includes a processor, or an instruction execution system, device, or other system that can execute those instructions. It may be propagated by or within any transmission medium for use with or with them. In the context of this specification, the "transmission medium" may be any medium capable of transmitting, propagating, or transmitting a program for use with or with an instruction execution system, device, or device. .. Transmission media may include, but are not limited to, electronic, magnetic, optical, electromagnetic, or infrared wired or wireless propagation media.

In some embodiments, the system 1600 may be included within the user device 110 or user server 114. Processor 1606 may be configured to perform processes 200, 300, 1000, f0, and 1500. It should be understood that the system is not limited to the components and components of FIG. 16 and may include other or additional components in multiple configurations according to various embodiments.

Although the present disclosure and examples have been fully described with reference to the accompanying drawings, it should be noted that various changes and modifications will be apparent to those skilled in the art. Such changes and amendments should be understood to be within the scope of the present disclosure and examples as defined by the appended claims.

Claims (7)

It's a method
The method comprising displaying a first plurality of compartments associated with the first user, wherein the each of the compartments of the first plurality of compartments, the identifier of one type of health data of the first user and measurements that are displayed, and that,
In response to receiving a request to view a second plurality of compartments associated with the second user, there by displaying the second plurality of sections associated with the second user Te, wherein the second respective compartments of a plurality of compartments, the identifier and the measured values of one type of health data of the second user still appears, and that,
Including methods. The method of claim 1, wherein the request for viewing the second plurality of compartments comprises a request for laterally scrolling the displayed first plurality of compartments. The method of claim 1, wherein the request for browsing the second plurality of compartments comprises selecting the second user from a list of users. The method according to any one of claims 1 to 3, wherein the first user is authorized by the second user to browse the second plurality of sections. It ’s an electronic device,
A memory containing one or more computer programs including an instruction to execute the method according to any one of claims 1 to 4.
With one or more processors capable of executing the instruction stored in the memory.
Equipped with an electronic device. A computer program comprising an instruction to execute the method according to any one of claims 1 to 4. An electronic device comprising means for performing the method according to any one of claims 1 to 4.

Images