JP7264953B2 - Presentation of physiological data - Google Patents

Description

The following disclosure relates generally to data management, and more specifically to aggregating and sharing health data.

About 133 million Americans currently suffer from at least one chronic disease. 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 individuals by providing tools to monitor and track their health data. Health data may generally include any type of data associated with human health, such as weight, heart rate, blood pressure, blood sugar levels, medication compliance, activity levels, and the like. Users can monitor their health using devices such as blood pressure 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. While each application can be used to display useful information about the user's health, 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 processes for aggregating and sharing health data. One exemplary process is causing an aggregated view of multiple types of health data to be displayed, the aggregated view including multiple parcels, each of the multiple parcels representing multiple types of health data. associated with a type of health data; receiving a selection of one of the plurality of compartments; and displaying an expanded view of the selected one of the plurality of compartments. and may include

In one embodiment, in the aggregated view, each section of the plurality of sections includes an identifier of the associated type of health data and a first portion of the associated type of health data displayed therewith. , the expanded view includes a larger view of a selected one of the plurality of compartments and a second portion of the associated type of health data displayed therewith. In another embodiment, the first portion of the health data includes the latest value of the associated type of health data and the second portion of the associated type of health data includes the associated type of health data. contains a chronological representation of

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

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

In one example, the multiple types of health data include weight data, blood glucose data, blood pressure data, activity data, or heart rate data. In another example, at least one of the multiple types of health data is generated from sensor data obtained from multiple sensors.

In one example, the expanded view includes graphs of associated types of health data, the graphs including segments generated from health data obtained from various sensors.

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

Another exemplary process is causing a plurality of compartments to be displayed on the device, each compartment of the plurality of compartments being associated with one type of health data among the multiple types of health data. and responsive to detecting a change in orientation of the device, selecting a subset of the plurality of compartments, and causing the selected subset of the plurality of compartments to be displayed.

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

In one example, each of the displayed subsets of the plurality of segments includes a graphical representation of at least a portion of the associated type of health data displayed therewith. In another example, selecting a subset of the plurality of parcels includes identifying correlations between the plurality of types of health data and determining parcels associated with the correlated types of health data into the plurality of parcels. selecting as a subset of .

Another exemplary process is causing a first plurality of parcels associated with a first user to be displayed, each parcel of the first plurality of parcels representing one type of first user. and in response to receiving a request to view a second plurality of parcels associated with the second user, a second plurality associated with the second user wherein each segment of the second plurality of segments is associated with one type of health data for the second user.

In one embodiment, the request to view the second plurality of panes includes a request to horizontally scroll the displayed first plurality of panes. In another example, the request to view the second plurality of parcels includes selecting the second user from the list of users.

In one embodiment, the first user is authorized by the second user to view the second plurality of parcels.

Another example process accesses the set of health data in response to receiving an identifier of a user authorized to access the set of health data and detecting an update to the set of health data. sending a notification to an authorized user to access the set of health data that an update to the set of health data has been detected; and at least one of the set of health data. transmitting the portion to a user authorized to access the set of health data.

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

Another example process includes receiving a request from a first user to access health data associated with a second user; transmitting a request to the second user for authorization to access by the second user; and transmitting health data associated with the second user to the first user in response to receiving authorization from the second user. and sending to the user.

In one example, the first user is a healthcare provider, the second user is a patient, and the request to access health data associated with the second user includes the first user and the first user. 2 is received prior to meeting with the user. In another example, a request to authorize the first user to access health data associated with the second user is displayed on the second user's mobile device.

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

1 is a block diagram of an exemplary system for aggregating health data, in accordance with various embodiments; FIG.

1 is a block diagram of an example system for sharing health data, in accordance with various embodiments; FIG.

FIG. 4 illustrates an exemplary process for performing authorization and pushing health data to other authorized users in accordance with various embodiments;

FIG. 10 illustrates an example process for authorizing a user to pull health data in accordance with various embodiments;

FIG. 10 illustrates an example interface for displaying aggregated health data, in accordance with various examples; FIG. 10 illustrates an example interface for displaying aggregated health data, in accordance with various examples; FIG. 10 illustrates an example interface for displaying aggregated health data, in accordance with various examples; FIG. 10 illustrates an example interface for displaying aggregated health data, in accordance with various examples; FIG. 10 illustrates an example interface for displaying aggregated health data, in accordance with various examples; FIG. 10 illustrates an example interface for displaying aggregated health data, in accordance with various examples;

FIG. 10 illustrates an example process for displaying aggregated health data, in accordance with various embodiments;

FIG. 10 illustrates an example interface for displaying aggregated health data, in accordance with various examples;

FIG. 10 illustrates an example process for displaying aggregated health data, in accordance with various embodiments;

FIG. 10 illustrates an example interface for displaying other users' aggregated health data in accordance with various embodiments.

FIG. 10 illustrates another example interface for displaying other users' aggregated health data in accordance with various embodiments;

FIG. 10 illustrates an example process for displaying other users' aggregated health data, in accordance with various embodiments;

1 illustrates an exemplary computer system for aggregating and sharing health data, in accordance with various embodiments; FIG.

In the following disclosure and description of examples, reference is made to the accompanying drawings in which specific examples that may be implemented are shown by way of illustration. It is to be understood that other examples may be implemented and structural changes may be made without departing from the scope of the present disclosure.

The present disclosure relates to aggregating and sharing health data. Health data may be received by the user device from any number of sensors external or internal to the user device, from a user manually entering health data, or from other users or entities. A user device may securely store health data on the user device and transmit health data for storage in a remote database. Device users may share some or all of their health data with friends, relatives, caregivers, health care providers, and the like. The user device may further display the user's health data within an aggregated view of various types of health data. For example, an aggregated view may include a set of parcels, each parcel corresponding to a different type of health data. Health data of other users may also be viewed if authorization is received from those users. In some embodiments, the parcels may be displayed as having the appearance of stacked cards and an associated animation, with each card corresponding to a different parcel (and therefore 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 data of the selected card including at least one of the first reconstructed data, the additional data, or an expanded view of the original data. One expanded view may be displayed. A second expanded view of the selected card may be displayed in response to a change in orientation of the user device. The second expanded view may include at least one of second reconstructed data, additional data, or an expanded view of the original data. In one example, the second expanded view may include graphs of health data over time.
System overview

FIG. 1A shows an exemplary system 100A for aggregating and sharing health data. As noted above, health data may include, but is not limited to, any type of data associated with human health such as weight, heart rate, blood pressure, blood sugar levels, medication compliance, activity level, and the like. The system 100A collects health data associated with the user, stores the health data, presents the health data to the user in a beneficial manner, and shares the user's health data with other users or entities based on permissions set by the user. May be used for selective sharing. Further, in some embodiments, 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, or the like. User device 110 may include an operating system and may store health or non-health data such as the time the data was recorded, the type of data, the device used to record the data, the user associated with the data, etc. A health database 111 may be included for secure storage along with associated metadata. User device 110 may further include an application programming interface (API) with access controls for storing data in health database 111 and for accessing data stored in health database 111. .

User device 110 may be configured to receive health or non-health data from various sources and store the received data within health database 111 . For example, user device 110 may be configured to receive health or non-health data from sensors 102 , 104 , 106 , and 108 . These sensors may include any type of sensor capable of obtaining health data, such as biometric sensors, activity trackers, and the like. For example, sensors 102, 104, 106, and 108 may include, but are not limited to, weight scales, blood pressure cuffs, blood glucose monitors, electrocardiograms, step counters, gyroscopes, accelerometers, SpO2 sensors, respiration sensors, posture sensors, Stress sensors, photoelectric finger plethysmograms, galvanic skin response sensors, temperature sensors, asthma inhalers, etc. may be included. Sensors 102, 104, 106, and 108 include audio sensors, ambient light sensors, electromagnetic sensors, touch sensors for obtaining non-health data such as situational data, time data, personal data, contact data, and similar data. , may also include other types of sensors such as capacitive sensors. In some examples, each sensor may be a separate device, while in other examples any combination of two or more of the sensors may be included within a single device. For example, gyroscopes, accelerometers, photoelectric plethysmograms, galvanic skin response sensors, and temperature sensors may be included in wearable electronic devices such as smartwatches, weight scales, blood pressure cuffs, The blood glucose monitor, SpO2 sensor, respiratory sensor, posture sensor, stress sensor, and asthma inhaler may each be separate devices. Although specific examples are provided, 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 obtain a single measurement or multiple measurements over a period of time. Sensors 102, 104, 106, and 108 may be configured to measure healthy or non-healthy data at the same time intervals, or may be configured to measure healthy or non-healthy data at different time intervals. good. These intervals may be set by the user or may be default settings for each sensor. Additionally, the sensors 102, 104, 106, 108 may be used to measure health or non-health data at any time or place desired by the user. Additionally, sensors 102, 104, 106, and 108 may be used with or without health care provider supervision. For example, a user may use sensors 102, 104, 106, and 108 to obtain sensor readings at home without the supervision of a medical professional.

In some examples, user device 110 is associated with each of sensors 102, 104, 106, and 108 to interface with the sensors to enable user device 110 to receive health or non-health data. software sensor application 113 (eg, a third party application). In these examples, application 113 may use the device's API to store health or non-health data in health database 111 of user device 110 . In some examples, software sensor application 113 may be an app, device 110 may be a smart phone, tablet computer, or the like. It should be appreciated that a “third party” can correspond to an entity different from the manufacturer of device 110 and/or the entity that created and/or maintains 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 protocols associated with device 110 .

Application 113 may also use the device's API to access data stored within health database 111 . In other examples, user device 110 communicates with one or more forms of communication with sensors 102, 104, 106, to enable user device 110 to receive and interpret health or non-health data from the sensors. and 108. The received data may then be stored within health database 111 of user device 110 .

User Device 110 may receive data from its own health or non-health data sensors 115 such as a GPS sensor, clock, gyroscope, accelerometer, from a user interacting with User Device 110, from another entity such as a doctor, or other non-health data. Health or non-health data may also be received from sensor sources. For example, even if health or non-health data is received from an application 117 on the user device 110, such as a clock application, a calendar application, a game application, an application from a health care provider, a messaging application, etc. using the device's APIs. good. Health or non-health data from application 117 may be from users interacting with the application, remote databases (e.g., medical website databases), health care providers (e.g., via the institution's app), and the like. good too. In these examples, usage of application 117 (e.g., length of time video game application played, time video game played, number of times stock application interacted, number of times social networking application interacted, social networking application user device 110 usage (e.g., length of call time or number of text messages sent as determined from a phone payment application; Internet browsing as determined from the device's browser) time), time spent listening to music or music determined from streaming radio applications, time spent using remote applications to control televisions, amount of time and money spent on shopping websites, spending on adult websites. (e.g., to identify addictions), weather data from weather applications (e.g., to determine how the weather affects the user's health), the user's life as determined from the calendar with specific people determined from the type of event (e.g., meeting, birthday, holiday, etc.) occurring in the contact list and/or calendar application and/or messaging application and/or phone of user device 110; interactions, etc. may be received by user device 110 and stored in health database 111 .

In some examples, at least one application (e.g., at least one of applications 113 and 117) on user device 110 uses health database 111 (for both storage and retrieval purposes) on user device 110. to and to sensor data generated by sensor 115 and/or sensor data generated by sensors 102, 104, 106, and 108 in user device 110. may be provided with settings selected by For example, an application for tracking a user's running sessions may be granted access to data generated by the GPS sensor of user device 110, but the user's blood pressure data stored within health database 111 may include It may be made inaccessible. In some embodiments, an entity other than the owner of user device 110 may set authorization settings for various applications on user device 110 . For example, the manufacturer of the user device 110 and/or the entity that created and/or maintains the operating system of the user device 110 may evaluate the applications so that they may contain the user's health data and/or generated or received by the user device 110 . may determine whether access to the acquired sensor data should be granted. In some implementations, these settings may be overridden by the user.

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

FIG. 1B shows a system 100B for sharing user health data. Referring to FIG. 1B, user server 114 is communicatively coupled to user device 110 via network 112, which may include the Internet, an intranet, or any other wired or wireless public or private network. User device 110 is configured to securely transmit aggregated health or non-health data and associated metadata stored on the device to user server 114 for storage in user database 116. may In some embodiments, the health or non-health data and associated metadata may be transferred for storage within user database 116 in response to an explicit request for such transfer by the user of device 110. may be sent to user server 114 at any time, but in other embodiments the health or non-health data is stored in user database 116 continuously, periodically, intermittently, or with any desired frequency. Data may be synchronized. In yet other embodiments, the user's health or non-health data may be stored only on user device 110 and 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 the health or non-health data to decrypt the data. It may be configured to securely store health data. Further, the health or non-health data stored within the user database 116 is stored anonymously (eg, without identification and/or personal information about the user (real name, username, time and location data, etc.)). good too. In this way, other users, hackers, and owners/operators of user database 116 cannot determine the user's identity associated with data stored within database 116 . In some embodiments, a user may access their health or non-health data stored in user database 116 from a different user device than the one used to upload the health or non-health data to user server 114. can access. In these cases, users may be required to provide login credentials to access their health or non-health data. User server 114 may be configured to perform authorization processing to restrict access to data in user database 116 .

System 100B may further include any number of other user devices 122 and 124 coupled to network 112 . In some examples, user devices 122 and 124 may be operated by the same user as user device 110 . In these cases, users can access their health or non-health data stored in user database 116 by providing appropriate credentials to user server 114 . In some examples, health and non-health data may be synchronized between user database 116 and one or more of user devices 110 , 122 , and 124 . In other examples, the users of user devices 122 and 124 may be different persons than the user of user device 110 . In these examples, users of devices 122 and 124 cannot access the health or non-health data of the user of user device 110 without the user's authorization of user device 110 . Health or non-health data may be shared with users of user devices 122 and 124 once authorization is granted. This data sharing is described in more detail below in connection with FIGS.

In some embodiments, any of the sources of health or non-health data described above continuously, intermittently, periodically, or at any other desired frequency or time interval, Or it may be configured to measure, generate, or receive non-health data. As such, health or non-health data may likewise be stored or updated in health database 111 or user database 116 continuously, intermittently, periodically, or at any other desired frequency or time interval. may The frequencies and time intervals used to measure, generate, receive, or store the health or non-health conditions may be the same or different. Further, these frequencies and intervals may be default values, or they may be set by the user to provide the user with updated health or non-health data for a desired length of time. good too.

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

As noted above, a user's health or non-health data may be stored within the user database 116 and may be shared with other users with the owning user's authorization. Other users may be friends, family members, caregivers, doctors, social media providers, or any type of user. Various types and levels of authorization may be granted to health or non-health data stored within health database 116 .

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

At block 204, the user's health or non-health data may be monitored by the user's device to determine if any updates to the data have been made. If no updates have 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 causes the process 200 to proceed to block 206, while in other embodiments, only changes to certain types of user's health or non-health data are performed. causes process 200 to proceed to block 206 .

At block 206, a notification may be sent to one or more other authorized users. For example, a notification may be sent from a 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. Processing may then proceed to block 208 .

At block 208, the updated health or non-health data may be sent to other authorized users. For example, updated health or non-health data may be transmitted from a 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 sent when another authorized user indicates that they would like to see updated health or non-health data; The updated health or non-health data may be sent to the user devices of other authorized users without receiving a request to view the data from the other authorized users.

Pushing health or non-health data performed using process 200 is useful in situations where a user wishes to continue to provide their caregiver or family member (or other user) with their most recent health or non-health data. It can be useful. For example, an elderly parent grants permission to push their health or non-health data to a child so that the child can monitor the health status or medication compliance of the elderly user at all times requesting this information from the parent. It can be easily monitored without the need.

In other examples, a user's health or non-health data may be shared with other users by allowing other users to pull the health or non-health data. FIG. 3 shows an exemplary process 300 for authorizing other users to pull health or non-health data. At block 302, a request may be received to access health or non-health data for a particular user. The request may identify the user associated with the requested health or non-health data and, optionally, the portion of the health or non-health data to be accessed. The identifier may include a username, real name, contact information, or any other identifier or credential 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 (e.g., user device 122 or 124) to the user's user device (e.g., user device 110) associated with the requested data. good too. The request may then be displayed to the user associated with the requested data by the user's device (eg, user device 110).

At block 306, it may be determined whether authorization from the user associated with the requested health or non-health data has been received. Authorization may be received in any manner. For example, a prompt may be displayed on the user's user device 110 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 non-health data may be sent to the entity that requested access to the health or non-health 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 requesting entity's device (eg, user device 122 or 124).

In some embodiments, process 300 may proceed without performing blocks 304 or 306 if authorization to access the user's health or non-health data was granted before the request was made at block 302. , block 302 may proceed to block 308 . For example, if a parent has authorized a child to access their health or non-health data, then at block 302 a request by the child for the parent's health or non-health data may be received, and at block 308 the requested Health or non-health data may be sent to the child without any intervention action by the parent.

Pulling health or non-health data using process 300 prevents other authorized users from having occasional access to the data without wanting to be constantly provided with updates to their health or non-health data. It will help you in your desired situation. For example, a physician may desire access to a patient's medical records and health or non-health data just prior to meeting with 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 . In response to receiving authorization from the patient, the requested data may be transmitted from user device 110 to the physician's computing device (eg, user device 122 or 124). In some examples, the received health or non-health data may be added to an electronic medical record (EMR) associated with the user.

In some implementations, whether using a push or pull sharing model, a user's health or non-health data cannot be permanently stored on the user device of another authorized user. In this manner, authorization can be revoked for these other users, thereby preventing other previously authorized users from accessing the user's health data. Additionally, in some embodiments, a report may be generated detailing or summarizing the user's health or non-health data. These reports may then be sent to any desired recipients via email, secure transfer, or the like. In still other examples, user device 110 may transmit some or all of the user's health or non-health data, such as medical insurance information, blood type, medical history, etc. using near field communication or another communication protocol. It may be configured to communicate to medical personnel. This may be useful when checking into a hospital or when relevant medical data is needed during a medical emergency.
Aggregated data view

As described above, the user device 110 aggregates health or non-health data associated with the user received from the user, from one or more of the sensors 102, 104, 106, and 108, or from sources other than sensors. It may be configured as 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 may be used by user device 110 to display a user's aggregated health or non-health data. Interface 400 may include any number of sections 402, 404, 406, 408, 410, and 412, each containing different types of health data associated with a user. In the aggregated view of FIG. 4, panes may be used to display partial views of portions of various types of health data. In the examples shown in FIGS. 4-9, 11, and 13-14, the compartments are illustrated as having the appearance and associated animation of stacked cards, each card being a different compartment (and therefore a different type). health data). However, it should be appreciated that the partitions may be displayed in any other desired manner.

Interface 400 may include a first section 402 that may contain the user's identifier (eg, name) displayed at the top of the interface. As shown, the name of the user of user device 110 , “John Smith,” is displayed on pane 402 . Interface 400 may further include buttons 401 for viewing health data associated with other users. This feature is described in more detail below in connection with FIGS.

Interface 400 may further include another section 404 displayed adjacent to section 402 so as to have the appearance of overlapping section 402 like a stack of cards. This section may include an indication of the type of health data contained on the section, and a partial view of some of the section's health data (eg, summary, example, etc.). Specifically, section 404 includes the word "weight" to indicate that the section contains weight data associated with user "John Smith." Section 404 may further include "John Smith's" most recent weight of "185 lbs."

Interface 400 may further include another section 406 displayed adjacent to section 404 so as to have the appearance of overlapping section 404 like a stack of cards. This section may include an indication of the type of health data contained on the section, and a partial view of some of the section's health data (eg, summary, example, etc.). Specifically, section 406 includes the word "blood glucose" to indicate that the section contains blood glucose data associated with user "John Smith." Section 406 may further include "John Smith's" most recent blood glucose level of "164 mg/dL".

Interface 400 may further include another section 408 displayed adjacent to section 406 so as to have the appearance of overlapping section 406 like a stack of cards. This section may include an indication of the type of health data contained on the section, and a partial view of some of the section's health data (eg, summary, example, etc.). Specifically, section 408 includes the word "blood pressure" to indicate that the section contains blood pressure data associated with user "John Smith." Section 408 may further include "John Smith's" most recent blood pressure reading "117/67 mmHg".

Interface 400 may further include another section 410 displayed adjacent to section 408 so as to have the appearance of overlapping section 408 like a stack of cards. This section may include an indication of the type of health data contained on the section, and a partial view of some of the section's health data (eg, summary, example, etc.). Specifically, section 410 includes the word "activity" to indicate that the section contains activity data (eg, calories burned) associated with user "John Smith." Plot 410 may further include "John Smith's" most recent calorie consumption per day of "467 kcal."

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

Some or all of the compartments may be static or dynamic. For example, the section 402 containing the user's name may remain at the top of the display, while the remaining sections display the time, how recently the health data associated with that section was updated, and the number associated with that section. may be ordered based on how often the collected health data is updated, whether an important event (eg, taking a drug, taking a sensor measurement, etc.) is approaching, and so on. The ordering may be changed manually by the user. If interface 400 includes more panes than can be displayed on a single screen, vertical scrolling may be performed to display the remaining panes. Alternatively, 3D scrolling of the compartments may be performed to provide the appearance of flipping through stacked cards.

Although specific compartment types are provided as examples above, it should be understood that compartments containing various types of health data may be included within the interface 400 . Additionally, the user may create customized panes 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 generated compartment. Other custom partitions for different health data types such as nutrition, sleep, smoking, etc. may also be generated.

Further, although the above provides specific examples of partial views (e.g., summary, example, etc.) of some of the parcel health data, the partial views summarize the example health data differently. or may be provided. For example, rather than displaying the most recent value for a particular health data type, health data average, mode, median, over all or part of time (e.g., week, month, year, etc.) Another single data point, etc. may be displayed on the parcel within the aggregated view. Alternatively, in other embodiments, the current and average values may be displayed on the parcels within the aggregated view. In still other examples, the sections within the aggregated view may include displays of current and target values for health data types.

to display an expanded view of the parcel, including reconstructed data, additional data, or a magnified view of the original data contained on the parcel 402, 404, 406, 408, 410; and 412 may be selected. For example, a user may select a segment by tapping the desired segment displayed on the touch-sensitive display, highlight and click the segment using a mouse or other input device, Or any other input means may be used to select the desired partition. In response to the selection of a section, user device 110 may hide the content of other sections and display the selected section on all or most of the display of user device 110 .

For example, FIG. 5 shows an exemplary interface 500 that may be displayed in response to a user selecting section 404 within interface 400 . In interface 500, expanded view 405 of section 404 may be prominently displayed within the display of user device 110, with the remaining sections displayed at the bottom of the display so that they disappear from the display. It may be animated as collapsing into stacked compartments 502 . In the illustrated example, expanded view 405 includes additional weight-related data not shown in interface 400, such as the user's weight, body mass index (BMI), and fat percentage. It's okay. The expanded view 405 further provides an overview of the user's weight data, such as a sliding scale 540 that shows the user's weight over a range of weights and a graph 541 that tracks the user's weight by day, week, month, or year. may contain. Interface 500 causes user device 110 to display options for sharing some or all of the user's health data using any desired communication medium, such as text messages, email, social media providers, etc. A button 504 may also be included to allow In these examples, health data may be encrypted and sent directly from user device 110 to the recipient's user device (rather than from user server 114), where the health data may be decrypted. A user may select (eg, tap, click, or otherwise select) a stacked parcel 502 to return to the aggregated view of parcels shown in interface 400 . It should be appreciated that the contents of interface 500 and expanded view 405 are provided as examples, and that expanded view 405 may instead include any type of weight-related data or summary of weight-related data.

FIG. 6 shows an exemplary interface 600 that may be displayed in response to a user selecting section 406 within interface 400 . In interface 600, expanded view 407 of section 406 may be prominently displayed within the display of user device 110, with the remaining sections displayed at the bottom of the display so that they disappear from the display. It may be animated as collapsing into stacked compartments 502 . In the illustrated example, expanded view 407 may include additional blood glucose-related data not shown in interface 400, such as the user's blood glucose and units. The expanded view 407 displays the user's blood glucose, such as a sliding scale 542 that shows the user's blood glucose after meals for a typical range of blood glucose levels, and a graph 543 that tracks the user's blood glucose by day, week, month, or year. A summary of blood glucose data may also be included. The interface 600 may also include the buttons 504 described above. A user may select (eg, tap, click, or otherwise select) a stacked parcel 502 to return to the aggregated view of parcels shown in interface 400 . It should be appreciated that the contents of interface 600 and expanded view 407 are provided as examples, and that expanded view 407 may instead include any type of glycemic-related data or summary of glycemic-related data.

FIG. 7 shows an exemplary interface 700 that may be displayed in response to a user selecting section 408 within interface 400 . In interface 700, expanded view 409 of parcel 408 may be prominently displayed within the display of user device 110, with the remaining parcels displayed at the bottom of the display such that they disappear from the display. It may be animated as collapsing into stacked compartments 502 . In the illustrated example, expanded view 409 may include additional blood pressure-related data not shown in interface 400, such as the user's blood pressure and beats per minute (bpm). The expanded view 409 provides an overview of the user's blood pressure data, such as a sliding scale 544 that shows the user's blood pressure relative to typical blood pressure values, and a graph 545 that tracks the user's blood pressure on a daily, weekly, monthly, or yearly basis. may further include The interface 700 may also include the button 504 described above. A user may select (eg, tap, click, or otherwise select) a stacked parcel 502 to return to the aggregated view of parcels shown in interface 400 . It should be appreciated that the contents of interface 700 and expanded view 409 are provided as examples, and that expanded view 409 may instead include any type of blood pressure-related data, or a summary of blood pressure-related data.

FIG. 8 shows an exemplary interface 800 that may be displayed in response to a user selecting section 410 within interface 400 . In interface 800, expanded view 411 of section 410 may be prominently displayed within the display of user device 110, with the remaining sections displayed at the bottom of the display so that they disappear from the display. It may be animated as collapsing into stacked compartments 502 . In the illustrated example, expanded view 411 may include additional activity-related data not shown in interface 400, such as the user's calories burned, steps taken, distance traveled, and the like. The expanded view 411 shows the user's blood pressure, such as a graph 546 that tracks the intensity of the user's activity by day, week, month, or year, and a summary 547 that shows total time spent in activity, rest, and exercise. A summary of the data may also be included. The interface 800 may also include the buttons 504 described above. A user may select (eg, tap, click, or otherwise select) a stacked parcel 502 to return to the aggregated view of parcels shown in interface 400 . The contents of interface 800 and expanded view 411 are provided as examples, and it should be appreciated that expanded view 411 may instead include any type of activity-related data, or a summary of activity-related data.

FIG. 9 shows an exemplary interface 900 that may be displayed in response to a user selecting section 412 within interface 400 . In interface 900, expanded view 413 of section 412 may be prominently displayed within the display of user device 110, with the remaining sections displayed at the bottom of the display so that they disappear from the display. It may be animated as collapsing into stacked compartments 502 . In the illustrated example, 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 parcels 404, 406, 408, and 410, this data is already available from the time parcel 412 is displayed in the aggregated view as being placed on top of the stacked parcels. It was displayed in interface 400 . The expanded view 413 may further include a summary of the user's heart rate data, such as a graph 548 that tracks the user's heart rate by day, week, month, or year. The interface 900 may also include the buttons 504 described above. A user may select (eg, tap, click, or otherwise select) a stacked parcel 502 to return to the aggregated view of parcels shown in interface 400 . The contents of interface 900 and expanded view 413 are provided as examples, and it is understood that expanded view 413 may alternatively include any type of heart rate-related data, or summary of heart rate-related data. sea bream.

In some examples, the user health data used to generate the interfaces shown in FIGS. 4-9 may have been 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 section. For example, the weight data shown in interface 500 of FIG. 5 may be obtained from repeated measurements taken using the same weight scale. Alternatively, some of the measurements may have been obtained from one scale and the remaining measurements from one or more different scales. As a result, some points in graph 541 may have been generated using weight data from one scale, while other points in graph 541 may have been generated using weight data from one or more other scales. It may have been generated using data. In another example, the activity data shown in interface 800 of FIG. 8 may have been obtained from a single step counting device. Alternatively, data is aggregated from the pedometer device, a first GPS-enabled watch used to record the user's running session, and a second GPS-enabled watch used to record the user's rowing session. may be In these illustrative examples, graph 546 depicting intensity of user activity is a segmented graph generated by combining data obtained from the step tracking device and the first and second GPS-enabled watches; Alternatively, each segment may originate from one of the devices. In particular, graph 546 shows a first segment 550 generated from data from a step counting device, a second segment 552 generated from data from a first GPS-enabled watch, and a second segment 552 generated from data from a second GPS-enabled watch. A third segment 554 generated from the data may also be included. Aggregating data in this manner is advantageous because it allows users to record and view health data in a manner that does not directly tie the health data to a particular device or application (e.g., smart phone application). Although three segments are shown in FIG. 8, it should be understood that the segmented graph can include any number of segments corresponding to different sensors and/or applications.

FIG. 10 shows an example process 1000 for displaying health data, in accordance with various embodiments. At block 1002 , an aggregated view of health data, including a plurality of segments similar or identical to segments 402 , 404 , 406 , 408 , 410 , and 412 is generated by a user similar or identical to user device 110 . May be displayed on the device. These compartments may include identifiers for the types of health data displayed on the compartments and partial views (eg, overviews, examples, etc.) of some of the health data types associated with the compartments. An interface similar or identical to interface 400 may be displayed, including, for example, various health data sections 402, 404, 406, 408, 410, and 412. FIG.

At block 1004, a selection of one of the displayed parcels may be received. This selection may be received by the user device and may be in the form of a mouse click, tap on a touch sensitive display, or the like. At block 1006, an expanded view of the selected parcel may be displayed in response to the parcel selection. The expanded view includes a view showing a larger portion of the selected compartment and reconstructed health data (eg, health data displayed on the selected compartment in the aggregated view displayed at block 1002). reordered view of the data), additional health data (e.g., health data not previously displayed on the selected segment within the aggregated view displayed at block 1002), or a magnified view of the health data displayed in the aggregated view displayed in block 1002 (eg, a larger view of the same health data displayed on the selected partition in the aggregated view displayed in block 1002); and at least one of. Additionally, the size of non-selected partitions may be reduced or they may be removed from the display. For example, any of interfaces 500, 600, 700, 800, or 900 may be displayed depending on selection of sections 404, 406, 408, 410, or 412 of interface 400, respectively.

In some examples, the display presented at block 1006 may include selectable options (eg, button 504) for sharing health data. In other examples, the display presented at block 1006 may further include a selectable option (eg, section 502) to redisplay the aggregated view including the section displayed at block 1002. . Processing may then return to block 1004, where a selection of another partition may be received.

FIG. 11 shows an example interface 1100 that may be displayed in response to the user rotating the user device 110 to landscape view. In this orientation, user device 110 may display an expanded view of a smaller subset of compartments than displayed in the aggregated view of interface 400 . For example, interface 1100 may include expanded view 1102 of section 408 , expanded view 1104 of section 406 , and expanded view 1106 of section 412 . In the illustrated example, the expanded view of the compartment may include graphical representations 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 relative to each other over time, and to see how changes in one type of health data affect another type of health data. Be able to assess how it relates to changes in data (or lack thereof). For example, one type of health data that may 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 examples, user device 110 may select the type of health data displayed when user device 110 is rotated to a landscape orientation. This selection may be made based on a predetermined combination of health data types that are often associated with each other, or may be made based on an analysis of various types of health data. In the latter example, the types of health data identified as potentially correlated may be displayed. Types of health data not displayed in the initial display of interface 1100 may be displayed by scrolling through the panes. Additionally, a partition may be selected in the same manner as performed in interface 400 to display more detailed information.

FIG. 12 illustrates an example process 1200 for displaying health data based on device orientation, in accordance with various embodiments. At block 1202 , an aggregated view including multiple parcels similar or identical to parcels 402 , 404 , 406 , 408 , 410 , and 412 is displayed by a user device similar or identical to user device 110 . may These compartments may include identifiers for the types of health data displayed on the compartments and partial views (eg, overviews, examples, etc.) of some of the health data types associated with the compartments. An interface similar or identical to interface 400 may be displayed, including, for example, various health data sections 402, 404, 406, 408, 410, and 412. FIG.

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

At block 1206, a subset of the plurality of parcels displayed at block 1202 may be selected for display. In some examples, the subset may be a predetermined subset of multiple compartments. In other embodiments, the subset may be selected based on user-defined display preferences. In yet another example, a subset of a plurality of compartments is selected from the health data set associated with each compartment to determine if any of the health data types are likely to be correlated. It may be selected based on analysis. If a potential correlation is identified, at block 1206, a partition associated with the potentially correlated data may be selected.

At block 1208, an expanded view of the subset of parcels selected at block 1206 may be displayed. In some examples, an identifier for the health data type displayed on the expanded view of the compartment and/or a summary, example, or other view of the health data type associated with the compartment is displayed at block 1202. may differ from that displayed on the compartment. For example, the summary or example data on each expanded view may be replaced with a graphical representation of health data over time, as shown in FIG. This allows observation of relationships between the types of health data displayed. In some examples, processing may return to block 1202 in response to detecting that the orientation of the user device has changed to a portrait orientation.

As noted above, in some embodiments, users of user devices 110 may be authorized to access health data of other users. In these examples, user device 110 may allow users to view other users' health data in a format similar to that described above in connection with FIGS. 4-12. For example, as shown in interface 1300 of FIG. 13, a user scrolls horizontally through the content of the interface in direction 1306 to view the health data of other users by scrolling through the first section of the section from the first user. 1304 may be displayed in place of the second set 1302 of parcels from the second user. In particular, a second set of panes 1302 for the second user may be translated in the direction of scrolling 1306 so that it disappears from the display, and a first plurality of panes 1304 are translated in the same direction 1306 out of the display. It may be translated onto the display from the opposite side. It should be appreciated that FIG. 13 shows a transition state in which pane 1302 is removed from the display and pane 1304 is about to be scrolled onto the display in direction 1306 . In this case, only the left side of section 1302 and the right side of section 1304 are shown. As panes 1302 and 1304 continue to scroll in direction 1306, smaller portions of pane 1302 are displayed and pane 1304 is displayed until pane 1302 is completely removed from the display and pane 1304 occupies all or most of the display. Larger portions may be displayed. Although not shown, the top pane of pane 1304 may contain the first user's name, which 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 through the panes for all users that the user of device 110 is authorized to access.

FIG. 14 shows another example interface 1400 for displaying health data of other users. In some examples, interface 1400 may be displayed in response to selection of button 401 of interface 400 . As shown, interface 1400 may include lists 1402, 1404, 1406, and 1408 of users who have authorized the user of user device 110 to access their health data. In some implementations, the circle next to each user's name may be replaced with an 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 example, users 1402, 1404, 1406, and 1408 are grouped into different categories (eg, Myself, Family, and Friends). These categories may be used to logically group users or, as described above, indicate authorization levels for viewing other users' health data. For example, users in the "family" category may have authorized a larger set of health data to be viewed, while users in the "friends" category may have authorized a smaller set of health data to be viewed. You may have Upon selection of one of users 1402, 1404, 1406, and 1408, section 1410 may be updated to reflect the selected user's health data. This is done by updating the types of health data displayed on the parcel (e.g., based on the types of health data that other users have authorized the user of user device 110 to view), as well as the types of health data associated with them. , updating a partial view (eg, summary, example, etc.) of a portion of the health data. In other examples, lists of users 1402, 1404, 1406, and 1408 may be displayed in response to vertically scrolling interface 400 up or down to display lists of users.

FIG. 15 illustrates an example process 1500 for displaying health data associated with two or more users, in accordance with various examples. At block 1502, a representation of a first plurality of parcels associated with a first user may be displayed. These sections may be similar or the same as sections 402 , 404 , 406 , 408 , 410 , and 412 and may be displayed by user devices similar or the same as user device 110 . These compartments may include identifiers for the types of health data displayed on the compartments and partial views (eg, overviews, examples, etc.) of some of the health data types associated with the compartments. An interface similar or identical to interface 400 may be displayed, including, for example, various health data sections 402, 404, 406, 408, 410, and 412. FIG.

At block 1504, a request to view a second plurality of parcels for a second user may be received. The second user may be a user who has authorized the first user to view his health data as described above. In some examples, the request may include user input to scroll the display of the first plurality of panes displayed at block 1502, rotation of the mouse wheel, arrow keys on a keyboard, touch-sensitive display. may be received by the user device in the form of touches and/or swipes of Similar to the example shown in FIG. 13, the scrolling direction may be horizontal with respect to the content of the display and may be vertical with respect to the scrolling direction causing additional panes associated with the first user to be displayed. good. However, it should be appreciated that other scrolling directions may be used. In other examples, the request to display the second plurality of panes may be received in the form of a second user's selection from a list of users. For example, the second user may be selected from a list of users similar to that shown in FIG. This list is displayed in response to selection of a button (eg, button 401) or other selection mechanism such as vertical scrolling of the first plurality of panes displayed at block 1502 to display the user's list. good too. In response to receiving a request to view the second plurality of parcels at block 1504 , processing may proceed to block 1506 .

At block 1506, a representation of a second plurality of parcels associated with a second user may be displayed. In some examples, if the request to view the second plurality of panes received at block 1504 included a request to scroll the display of the first plurality of panes, then FIG. , a first plurality of segments may be translated in the direction of scrolling to disappear from the display, and a second plurality of segments may be translated in the same direction from the opposite side of the display onto the display. It may be translated. In another example, if the request to view the second plurality of parcels received at block 1504 included selection of the second user from the list of users, as shown in FIG. , the first plurality of compartments may be replaced with a representation of the second plurality of compartments. for viewing sections of health data of other users to display some or all of the set of sections associated with users who have authorized the user of device 110 to view their health data; Additional requests may be received and blocks 1504 and 1506 may be repeated.

It should be appreciated that the processes described above may be combined. For example, process 1200 may be combined with process 1000 such that blocks 1204, 1206, and 1208 are performed in response to a change in orientation of the user device after multiple panes are displayed at block 1002. FIG. Similarly, process 1500 may display multiple parcels associated with another user in response to receiving a request to view parcels associated with another user after multiple parcels have been displayed at block 1002 . It may be combined with process 1000 such that blocks 1504 and 1506 are executed for display.

As described above, 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 Similarly, processes 1000, 1200, and 1500 are performed to update the display of health or non-health data continuously, intermittently, periodically, or at any other desired frequency or time interval. may For example, a device performing processes 1000, 1200, or 1500 may retrieve updated health or non-health data from health database 111 or user database 116 continuously, intermittently, periodically, or any other desired method. may be received at a frequency or time interval of In some examples, a device performing processes 1000, 1200, or 1500 may receive updates to all health or non-health data at the same frequency or time interval. In other embodiments, devices performing processes 1000, 1200, or 1500 may be configured to receive updates to various types of data at different frequencies or time intervals. For example, heart rate data may be updated on a second-by-second basis, and weight data may be updated on a daily-by-day basis. These intervals and frequencies may be default values or may be selected by the user.

One or more of the functions related to health data aggregation and sharing may be performed by a system similar or identical to system 1600 shown in FIG. System 1600 may include instructions stored in a non-transitory computer-readable storage medium such as memory 1604 or storage device 1602 and executed by processor 1606 . Instructions may also refer to an instruction execution system, apparatus, or instruction execution system, such as a computer-based system, a system that includes a processor, or any other system capable of fetching instructions from and executing those instructions. It may be stored and/or transmitted on any non-transitory computer-readable storage medium for use by or with the device. In the context of this specification, a "non-transitory computer-readable storage medium" is any medium capable of containing or storing a program for use by or with an instruction execution system, apparatus, or device. good too. Non-transitory computer-readable storage media include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, equipment, or devices, portable computer diskettes (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 also include portable optical discs such as DVD-R or DVD-RW, or flash memory such as compact flash cards, secure digital cards, USB memory devices, memory sticks.

Instructions may also refer to an instruction execution system, apparatus, or instruction execution system, such as a computer-based system, a system that includes a processor, or any other system capable of fetching instructions from and executing those instructions. It may be propagated in any transmission medium for use by or with devices. In the context of this specification, a "transmission medium" may be any medium capable of carrying, propagating, or transmitting a program for use by or with an instruction execution system, apparatus, or device. . Transmission media may include, but are not limited to, electronic, magnetic, optical, electromagnetic, or infrared wire or wireless transmission media.

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

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 become apparent to those skilled in the art. Such changes and modifications are to be understood to fall within the scope of the disclosure and examples as defined by the appended claims.

Claims (6)

a method,
receiving from a first user associated with a set of health data an identifier of a second user authorized to access said set of health data, said identifier of said second user being , including levels of access to particular subsets of said set of health data;
In response to detecting an update to said set of health data,
transmitting a notification to the second user authorized to access the set of health data, the notification indicating that the update to the set of health data has been detected; informing the second user authorized to access the set;
transmitting at least a portion of the set of health data to the second user authorized to access the set of health data;
A method. 2. The method of claim 1, wherein the identifier of the second user authorized to access the set of health data comprises a name, username, or contact information.
Method. 3. The method of any one of claims 1-2, wherein the at least part of the set of health data is requested from the second user authorized to access the set of health data. sent in response to receiving a
Method. A computer program that causes a computer to execute the method according to any one of claims 1 to 3. an electronic device,
a memory storing the computer program according to claim 4;
one or more processors capable of executing the computer program stored in the memory;
An electronic device comprising: An electronic device comprising means for performing the method according to any one of claims 1-3.

Images