JP6643384B2 - Presentation of physiological data - Google Patents

Description

  The following disclosure relates generally to data management, and more particularly 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. For this reason, the cost of health care in the United States is expected to increase dramatically. Attempts have been made to improve each person's health by providing tools for monitoring and tracking their health data. Health data can typically include any type of data associated with human health, such as weight, heart rate, blood pressure, blood sugar, medication compliance, activity levels, and the like. 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. While each application can be used to display useful information about a user's health, current applications have the ability to allow users to store, display, and share health data collected by different devices Is restricted.

  The present disclosure relates to a process for aggregating and sharing health data. One exemplary process is to display an aggregated view of multiple types of health data, wherein the aggregated view includes multiple partitions, and each partition of the multiple partitions has multiple types of health data. Being associated with one 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 be included.

  In one embodiment, in the aggregated view, each compartment of the plurality of compartments 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 the selected section of the plurality of sections, and a second portion of the associated type of health data displayed therewith. In another example, the first portion of the health data includes an updated 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. Including the expression over time.

  In one embodiment, displaying the expanded view of the selected parcel includes displaying a collapsed set of parcels representing non-selected parcels of the plurality of parcels. In another example, the plurality of 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 includes a selectable element for sharing health data associated with the parcel via email or text message.

  In one embodiment, the plurality of types of health data include 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 obtained from a plurality of sensors.

  In one example, the expanded view includes a graph of the associated type of health data, where the graph includes segments generated from health data obtained from various sensors.

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

  Another exemplary process is to display a plurality of partitions on the device, wherein each of the plurality of partitions is associated with one type of health data of the plurality of types of health data. And selecting a subset of the plurality of partitions in response to detecting a change in device orientation, and displaying the selected subset of the plurality of partitions.

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

  In one embodiment, each of the displayed subsets of the plurality of compartments includes a graphical representation of at least a portion of the associated type of health data displayed therewith. In another embodiment, selecting a subset of the plurality of compartments includes identifying a correlation between the plurality of types of health data and combining the compartments associated with the correlated types of health data with the plurality of compartments. And selecting as a subset of.

  Another example process is to display a first plurality of parcels associated with a first user, wherein each parcel of the first plurality of parcels is one type of first user. Associated with the second user associated with the second user in response to receiving a request to view a second plurality of compartments associated with the second user. May be displayed, wherein each section of the second plurality of sections is associated with one type of health data of the second user.

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

  In one example, the first user has been authorized by the second user to view the second plurality of parcels.

  Another exemplary process includes accessing 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 the authorized user to inform the authorized user of accessing 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 embodiment, the identifier of the user authorized to access the set of health data includes a name, a user name, 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, and providing the first user with health data associated with the second user. Sending a request to authorize access to the second user, and responsive to receiving authorization from the second user, the health data associated with the second user to the first user. Transmitting to the user.

  In one embodiment, the first user is a health care provider, the second user is a patient, and the request to access health data associated with the second user is between the first user and the first user. Received before the meeting with the second user. In another example, a request to authorize a first user to access health data associated with a second user is displayed on the second user's mobile device.

  A system and a non-transitory computer readable storage medium for performing these processes are also provided.

FIG. 2 is a block diagram of an exemplary system for aggregating health data, according to various embodiments.

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

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

FIG. 9 illustrates an exemplary process for authorizing a user to pull health data, according to various embodiments.

FIG. 4 illustrates an example interface for displaying aggregated health data, according to various embodiments. FIG. 4 illustrates an example interface for displaying aggregated health data, according to various embodiments. FIG. 4 illustrates an example interface for displaying aggregated health data, according to various embodiments. FIG. 4 illustrates an example interface for displaying aggregated health data, according to various embodiments. FIG. 4 illustrates an example interface for displaying aggregated health data, according to various embodiments. FIG. 4 illustrates an example interface for displaying aggregated health data, according to various embodiments.

FIG. 4 illustrates an exemplary process for displaying aggregated health data, according to various embodiments.

FIG. 4 illustrates an example interface for displaying aggregated health data, according to various embodiments.

FIG. 4 illustrates an exemplary process for displaying aggregated health data, according to various embodiments.

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

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

FIG. 7 illustrates an exemplary process for displaying aggregated health data of another user, according to various embodiments.

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

  In the following description of the disclosure and examples, reference is made to the accompanying drawings that show by way of illustration specific examples that may be practiced. It is to be understood that other examples can be implemented and structural changes can 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. The user device may store the health data securely on the user device and send the health data for storage in a 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, with each compartment corresponding to a different type of health data. If authorizations from those users are received, the health data of other users can also be viewed. In some embodiments, the parcels may be displayed as having a stacked card appearance and associated animation, with each card corresponding to a different parcel (and hence a different type 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, a second one of the selected cards including at least one of the first reconstructed data, additional data, or an expanded view of the original data. One expanded view may be displayed. In response to a change in orientation of the user device, a second expanded view of the selected card may be displayed. The second expanded view may include at least one of the second reconstructed data, additional data, or an expanded view of the original data. In one embodiment, the second expanded view may include a graph of health data over time.
System overview

  FIG. 1A illustrates an exemplary system 100A for aggregating and sharing health data. As discussed above, health data may include any type of data associated with human health, such as, but not limited to, weight, heart rate, blood pressure, blood glucose, medication compliance, activity levels, and the like. System 100A collects health data associated with the user, stores the health data, provides the health data to the user in a beneficial manner, and communicates the user's health data with other users or entities based on the user's permission set. It may be used to selectively share. 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 devices such as mobile phones, tablet computers, desktop computers, laptop computers, PDAs, and 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 for secure storage with associated metadata may be included. The user device 110 may further include an application programming interface (API) with access controls for storing data in the health database 111 and accessing data stored in the health database 111. .

  User device 110 may be configured to receive health or non-health data from various sources and store the received data in 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 a biometric sensor, activity tracking device, and the like. For example, sensors 102, 104, 106, and 108 include, but are not limited to, a scale, a sphygmomanometer cuff, a blood glucose monitor, an electrocardiogram, a step counter, a gyroscope, an accelerometer, an SpO2 sensor, a respiratory sensor, a posture sensor, It may include a stress sensor, a photoelectric finger plethysmogram, a galvanic skin response 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 obtaining non-health data such as situational data, time data, personal data, contact data, and similar data. And other types of sensors, such as capacitive sensors. 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 in a single device. For example, gyroscopes, accelerometers, photoelectric finger plethysmograms, galvanic skin response sensors, and temperature sensors may be included in wearable electronic devices such as smartwatches, while weight scales, sphygmomanometer cuffs, The blood glucose monitor, SpO2 sensor, respiration sensor, posture sensor, stress sensor, and asthma inhaler may each be a separate device. Although specific embodiments 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 acquire a single measurement or multiple measurements over a period of time. Sensors 102, 104, 106, and 108 may be configured to measure health or non-health data at the same time interval, or may be configured to measure health or non-health data at different time intervals. Good. These intervals may be set by the user or may be default settings for each sensor. Further, sensors 102, 104, 106, 108 may be used to measure health or non-health data at any time or location desired by the user. Further, sensors 102, 104, 106, and 108 may be used with or without monitoring by a health care provider. For example, a 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 each of the sensors 102, 104, 106, and 108 for connecting to the sensor and enabling the user device 110 to receive health or non-health data. Software application 113 (eg, a third-party application). In these embodiments, application 113 may use the device's API to store health or non-health data in user device 110's health database 111. In some embodiments, software sensor application 113 may be an app, and device 110 may be a smartphone, tablet computer, or the like. It should be understood that a "third party" may correspond to a different entity than the manufacturer of the device 110 and / or the entity that created and / or maintains the operating system of the 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 a predefined device protocol associated with device 110.

  The application 113 may similarly use the device's API to access data stored in the health database 111. In other embodiments, the user device 110 may use one or more types of communication with the sensors 102, 104, 106, to enable the user device 110 to receive and interpret health or non-health data from the sensors. 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 may communicate 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 physician, or from other non-health data. Health or non-health data may also be received from the sensor source. For example, health or non-health data may be 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 API. Good. The health or non-health data from the application 117 may be from a user interacting with the application, a remote database (eg, a database on a medical website), a health care provider (eg, via an institutional app), etc. Is also good. In these examples, the usage status of the application 117 (eg, the length of time the video game application was played, the time the video game was played, the number of interactions with the stock application, the number of interactions with the social networking application, the social networking application The length of talk time or the number of text messages sent from the phone payment application, the Internet browsing determined from the device's browser, etc. Time, etc.), music or music viewing time as determined from a streaming radio application, time using a remote application to control a television, on a shopping website The amount of time and money spent, time spent on adult websites (eg, to identify addictions), and weather data from weather applications (eg, how weather affects user health) The type of events that occur in the user's life determined from the calendar (e.g., meeting people, birthdays, holidays, etc.), a contact list and / or a calendar application and / or a messaging application and / or Alternatively, the interaction with the specific people determined from the user device 110's phone call may be received by the user device 110 and stored in the health database 111.

  In some embodiments, at least one application (eg, at least one of applications 113 and 117) on user device 110 has a health database 111 on user device 110 (for both storage and retrieval purposes). Default or user to limit access to and to sensor data generated by sensors 115 in user device 110 and / or sensor data generated by sensors 102, 104, 106 and 108. May be provided. For example, an application for tracking a user's running session may be authorized to access data generated by a GPS sensor on the user device 110, but the user's blood pressure data stored in the health database 111 It may be made inaccessible. In some embodiments, entities 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 maintains the operating system of the user device 110 evaluates the applications so that they are generated or received by the user's health data and / or the user device 110 A determination may be made as to whether access rights to the obtained sensor data should be granted. In some embodiments, 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 interface of the display of the user device 110 is described below in connection with FIGS.

  FIG. 1B shows a system 100B for sharing a user's health data. Referring to FIG. 1B, user server 114 is communicatively coupled to user device 110 via a 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. You may. In some embodiments, the health or non-health data and associated metadata may be stored in the user database 116 in response to such a transfer being explicitly requested by the user of the device 110. However, in other embodiments, the health or non-health data may be continuously, periodically, intermittently, or at any desired frequency in the user database 116. It may be synchronized with the data. In still other embodiments, the user's health or non-health data may be stored only on the user device 110 and may not be stored 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, using a public / private key system. Health data may be configured to be stored securely. Further, the health or non-health data stored in the user database 116 may be stored anonymously (eg, without identification and / or personal information about the user (real name, user name, time and location data, etc.)). Is also good. In this manner, other users, hackers, and the owner / operator of the user database 116 cannot determine the identity of the user associated with the data stored in the database 116. In some embodiments, a user may access his or her health or non-health data stored in user database 116 from a different user device than was used to upload the health or non-health data to user server 114. Can be accessed. In these cases, the user may be required to provide login credentials to access their health or non-health data. The user server 114 may be configured to perform an authorization process for restricting 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, user devices 122 and 124 may be operated by the same user as 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 example, the user of the user devices 122 and 124 may be a different person than the user of the user device 110. In these examples, the users of devices 122 and 124 may not access the health or non-health data of the user of user device 110 without authorization of the user of user device 110. Once granted, health or non-health data can be shared with users of user devices 122 and 124. This sharing of data is described in more detail below in connection with FIGS.

  In some embodiments, any of the above-mentioned sources of health or non-health data may be continuously, intermittently, periodically, or at any other desired frequency or time interval. Or, it may be configured to measure, generate, or receive non-healthy data. To this end, health or non-health data may also be stored or updated in the health database 111 or the user database 116 continuously, intermittently, periodically, or at any other desired frequency or time interval. You may. The frequency and time intervals used to measure, generate, receive, or store a health or non-health condition 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 during the desired length of time. Is also good.

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

  As described 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 the like. Various types and levels of authorization may be given to the health or non-health data stored in the health database 116.

  In some embodiments, the shared health or non-health data may be pushed to another authorized user device of the user (eg, user device 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, an identifier of another authorized user may be received. This may be received by a user device (eg, user device 110) from a user associated with the shared health or non-health data. The identifier may include a username, real name, contact information, or any other identifier or credential for another user, along with the level of access, such as access to all or a subset of the health or non-health data. May be included. In some embodiments, other authorized users may be grouped into categories of users (e.g., family, friends, other people, etc.), and each category may have their other authorized users. Associated with a particular set of types of health data that the user is authorized to view. For example, a user in the family category may be allowed to view all types of health data, while a user 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 whether any updates to the data have been made. If no updates have been made, the process may repeat block 204. However, if an addition or change to the user's health or non-health data is identified, processing may proceed to block 206. In some embodiments, any changes to the user's health or non-health data cause 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 Advances process 200 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 to the user's health or non-health data has been made. Next, processing may 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 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 be sent only if another authorized user indicates that they want to view updated health or non-health data, and in other embodiments, The updated health or non-health data may be transmitted to the authorized other user's user device without receiving a request from another authorized user to view the data.

  The push of health or non-health data performed using the process 200 is useful in situations where a user wishes to continue to provide his or her latest health or non-health data to a caregiver or family (or other user). May be useful. For example, an elderly parent may grant this permission to push their health or non-health data to the child, so that the child always asks the parent for the health or medication compliance of the elderly user. It can be easily monitored without need.

  In other embodiments, a user's health or non-health data may be shared with other users by allowing other users to pull health or non-health data. FIG. 3 illustrates an exemplary process 300 for authorizing another user to pull health or non-health data. At block 302, a request to access health or non-health data for a particular user may be received. The request may specify the requested health or non-health data and, optionally, the user associated with the portion of the health or non-health data to be accessed. The identifier may include the 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 a user associated with the requested health or non-health data. In some embodiments, the request is transmitted 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. Is also 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 an authorization from a 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 device 110 of the user associated with the requested data. If authorization is denied, processing may return to block 302. However, if authorization has been granted, processing may proceed to block 308.

  At block 308, the requested health or non-health data may be transmitted 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, if authorization to access the user's health or non-health data has been granted prior to the request being made at block 302, the process 300 may proceed without performing blocks 304 or 306. , Block 302 may proceed to block 308. For example, if the parent has granted the child access to their health or non-health data, a request for the parent's health or non-health data by the child may be received at block 302 and the requested at block 308 Health or non-health data may be sent to the child without any intervention by the parent.

  The pulling of health or non-health data using the process 300 may not allow other authorized users to be constantly provided with updates to the user's health or non-health data, and may provide irregular access to the data. Will help in the situation you want. For example, a physician may wish to access a patient's medical records and health or non-health data shortly before 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 a physician's computing device (eg, user device 122 or 124). In some embodiments, the received health or non-health data may be added to an electronic medical record (EMR) associated with the user.

In some embodiments, regardless of whether the push or pull sharing model is used, the user's health or non-health data cannot be permanently stored on the user device of another authorized user. In this way, authorization for these other users can be revoked, thereby preventing other previously authorized users from accessing the user's health data. Further, in some embodiments, a report may be generated that details or summarizes a user's health or non-health data. These reports may then be sent to any desired recipient via email, secure transfer, and the like. In yet other embodiments, the user device 110 may communicate 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 a healthcare professional. This may be useful when checking in to a hospital or when medical data related to a medical emergency is needed.
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 sensors 102, 104, 106, and 108, or from sources other than 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 illustrates one exemplary interface 400 that may be used by the user device 110 to display aggregated health or non-health data for a user. Interface 400 may include any number of compartments 402, 404, 406, 408, 410, and 412, each containing a different type of health data associated with the user. In the aggregated view of FIG. 4, parcels 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 parcels are illustrated as having the appearance of stacked cards and associated animations, with each card having 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 manner.

  Interface 400 may include a first pane 402, which may include an identifier (eg, name) of a user, displayed at the top of the interface. As shown, the name of the user of the user device 110 "John Smith" is displayed on the section 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.

  The interface 400 may further include another compartment 404 displayed adjacent to the compartment 402 to have an appearance overlapping the compartment 402 like a stacked card. The section may include an indication of the type of health data included on the section and a partial view (eg, overview, example, etc.) of a portion of the section's health data. Specifically, section 404 includes the word "weight" to indicate that the section includes weight data associated with 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 displayed adjacent to the compartment 404 so as to have an appearance overlapping the compartment 404 like a stacked card. The section may include an indication of the type of health data included on the section and a partial view (eg, overview, example, etc.) of a portion of the section's health data. Specifically, section 406 includes the word “blood sugar” to indicate that the section includes blood glucose data associated with user “John Smith”. Section 406 may further include the latest blood glucose value of “John Smith”, “164 mg / dL”.

  Interface 400 may further include another compartment 408 displayed adjacent to compartment 406 so as to have an appearance overlapping compartment 406 like a stacked card. The section may include an indication of the type of health data included on the section and a partial view (eg, overview, example, etc.) of a portion of the section's health data. Specifically, section 408 includes the word “blood pressure” to indicate that the section includes blood pressure data associated with user “John Smith”. Section 408 may further include the latest blood pressure measurement of “John Smith”, “117/67 mmHg”.

  The interface 400 may further include another compartment 410 displayed adjacent to the compartment 408 so as to have an appearance overlapping the compartment 408 like a stacked card. The section may include an indication of the type of health data included on the section and a partial view (eg, overview, example, etc.) of a portion of the section's health data. Specifically, section 410 includes the word “activity” to indicate that the section includes activity data (eg, calories burned) associated with user “John Smith”. Section 410 may further include “John Smith” 's latest calorie consumption per day “467 kcal”.

  Interface 400 may further include another compartment 412 displayed adjacent to compartment 410 so as to have an appearance overlapping compartment 410 like a stacked card. The section may include an indication of the type of health data included on the section and a partial view (eg, overview, example, etc.) of a portion of the section's health data. Specifically, section 412 includes the word "heart rate" to indicate that the section includes heart rate data associated with user "John Smith". Section 412 may further include the latest heart rate measurement "122 bpm" of "John Smith". Further, because section 412 is at the top of the stacked section, additional information 414 and / or options 416 may be displayed on the face of the section. In the illustrated example, the additional information includes the minimum, maximum, and resting heart rate of "John Smith" over the one week period selected using option 416.

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

  Although specific partition types have been provided above as examples, it should be understood that partitions containing various types of health data may be included in interface 400. Further, the user may create a customized section that can be used to display any desired type of data entered by the user. For example, a section for tracking the user's medication compliance may be created. The user may enter the time, amount and type of medication, and this data may be displayed on the created section. Other custom compartments for different types of health data, such as nutrition, sleep, smoking, etc., may also be generated.

  Further, while the above has provided a specific example of a partial view (eg, overview, example, etc.) of a portion of a parcel's health data, the partial view summarizes the health data example in a different manner. Or it may be provided. For example, rather than displaying the most recent value for a particular health data type, the average, mode, median, or health value of the health data over all or part of the time (eg, week, month, year, etc.) Another single data point or the like may be displayed on a parcel in the aggregated view. Alternatively, in other embodiments, the current value and the average value may be displayed on a partition in the aggregated view. In yet another embodiment, the partitions in the aggregated view may include an indication of a current value and a target value for the type of health data.

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

  For example, FIG. 5 illustrates an example interface 500 that may be displayed in response to a user selecting a partition 404 in the interface 400. In interface 500, an expanded view 405 of section 404 may be prominently displayed in the display of user device 110, with the remaining sections being displayed at the bottom of the display so that they disappear from the display. It may be animated as being folded into stacked section 502. In the illustrated embodiment, the expanded view 405 includes additional weight-related data not shown in the interface 400, such as the user's weight, body mass index (BMI), and fat percentage. May be. The expanded view 405 further summarizes the user's weight data, such as a sliding scale 540 showing 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 be included. The interface 500 causes the user device 110 to display options for sharing some or all of the user's health data using any desired communication medium, such as a text message, email, social media provider, and the like. A button 504 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, where the health data may be decrypted. To return to the aggregated view of the parcels shown in interface 400, the user may select (eg, tap, click, or otherwise select) stacked parcels 502. It should be appreciated that the content of the interface 500 and the expanded view 405 are provided as examples, and that the expanded view 405 may instead include any type of weight-related data, or a summary of weight-related data.

  FIG. 6 illustrates an exemplary interface 600 that may be displayed in response to a user selecting a partition 406 in interface 400. In interface 600, an expanded view 407 of section 406 may be prominently displayed in the display of user device 110, with the remaining sections being displayed at the bottom of the display so that they disappear from the display. It may be animated as being folded into stacked section 502. In the illustrated embodiment, the expanded view 407 may include additional blood glucose related data not shown in the interface 400, such as the user's blood glucose and units. The expanded view 407 includes a sliding scale 542 that shows the user's blood glucose after a meal for a typical blood glucose range, 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. Interface 600 may also include buttons 504 described above. To return to the aggregated view of the parcels shown in interface 400, the user may select (eg, tap, click, or otherwise select) stacked parcels 502. It should be understood that the content of interface 600 and expanded view 407 are provided by way of example, and expanded view 407 may instead include any type of blood glucose related data, or a summary of blood glucose related data.

  FIG. 7 illustrates an example interface 700 that may be displayed in response to a user selecting a section 408 in the interface 400. In the interface 700, an expanded view 409 of the section 408 may be prominently displayed in the display of the user device 110, with the remaining sections being displayed at the bottom of the display so that they disappear from the display. It may be animated as being folded into stacked section 502. In the illustrated embodiment, the expanded view 409 may include additional blood pressure related data not shown in the interface 400, such as the user's blood pressure and beats per minute (bpm). The expanded view 409 provides a summary of the user's blood pressure data, such as a sliding scale 544 that shows the user's blood pressure against typical blood pressure values and a graph 545 that tracks the user's blood pressure by day, week, month, or year. May be further included. Interface 700 may also include buttons 504 described above. To return to the aggregated view of the parcels shown in interface 400, the user may select (eg, tap, click, or otherwise select) stacked parcels 502. It should be understood that the content of interface 700 and expanded view 409 are provided as examples, and expanded view 409 may instead include any type of blood pressure-related data, or a summary of blood pressure-related data.

  FIG. 8 illustrates an example interface 800 that may be displayed in response to a user selecting a partition 410 in the interface 400. In interface 800, an expanded view 411 of section 410 may be prominently displayed in the display of user device 110, with the remaining sections being displayed at the bottom of the display so that they disappear from the display. It may be animated as being folded into stacked section 502. In the illustrated embodiment, expanded view 411 may include additional activity-related data not shown in interface 400, such as calories burned, steps taken, and distance traveled by the user. The expanded view 411 includes 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 the total time spent on activity, rest, and exercise. A summary of the data may also be included. Interface 800 may also include buttons 504 described above. To return to the aggregated view of the parcels shown in interface 400, the user may select (eg, tap, click, or otherwise select) stacked parcels 502. It should be understood that the content of the interface 800 and the expanded view 411 are provided as examples, and the expanded view 411 may instead include any type of activity-related data, or a summary of activity-related data.

  FIG. 9 illustrates an example interface 900 that may be displayed in response to a user selecting a partition 412 in interface 400. In the interface 900, an expanded view 413 of the section 412 may be prominently displayed in the display of the user device 110, and the remaining sections are displayed at the bottom of the display so as to disappear from the display. It may be animated as being folded into stacked section 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 parcels 404, 406, 408, and 410, this data is no longer available when parcel 412 is displayed in the aggregated view as being located at the top of the stacked parcels. It is displayed in the 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. Interface 900 may also include buttons 504 described above. To return to the aggregated view of the parcels shown in interface 400, the user may select (eg, tap, click, or otherwise select) stacked parcels 502. It is understood that the contents of interface 900 and expanded view 413 are provided as examples, and expanded view 413 may instead include any type of heart rate-related data, or a summary of heart rate-related data. I want to.

  In some embodiments, the user's health data used to generate the interface shown in FIGS. 4-9 may have been received from one or more sensor devices and / or applications. In these embodiments, the same type of health data from different devices may be combined and displayed on a single pane. For example, the weight data shown in the interface 500 of FIG. 5 may be obtained from repeated measurements made using the same scale. Alternatively, some of the measurements may be obtained from one scale and the remaining measurements may be obtained from one or more different scales. As a result, some points in graph 541 may have been generated using weight data from one weighing scale, and other points in graph 541 may have been generated using weighting data from one or more other weighing scales. It may be generated using data. In another example, the activity data shown in interface 800 of FIG. 8 may have been obtained from a single pedometer device. Alternatively, data is aggregated from a 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 done. In these examples, the graph 546 showing the intensity of the user's activity is a segmented graph generated by combining data obtained from the step tracking device and the first and second GPS-enabled watches. Each segment may originate from one of the devices. In particular, graph 546 includes 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 be included. Aggregating the data in this manner is advantageous because the user can record and view the health data in a manner that does not directly tie 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 may include any number of segments corresponding to different sensors and / or applications.

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

  At block 1004, a selection of one of the displayed partitions may be received. This selection may be received by the user device and may be in the form of a mouse click, a tap on a touch-sensitive display, or the like. At block 1006, in response to the selection of a parcel, an expanded view of the selected parcel may be displayed. The expanded view includes a view showing a larger portion of the selected section and a view of the reconstructed health data (eg, health displayed on the selected section in the aggregated view displayed in block 1002). A rearranged view of the data), additional health data (e.g., health data not previously displayed on the selected pane in the aggregated view displayed at block 1002), or displayed at block 1002. Of an enlarged view of the health data displayed in the aggregated view (eg, a larger view of the same health data displayed on a selected pane in the aggregated view displayed in block 1002). At least one of them may be included. Further, the size of the unselected sections may be reduced or the sections may be deleted from the display. For example, any of the interfaces 500, 600, 700, 800, or 900 may be displayed depending on the selection of the section 404, 406, 408, 410, or 412 of the interface 400, respectively.

  In some embodiments, the display presented at block 1006 may include selectable options (eg, button 504) for sharing health data. In another example, the display presented at block 1006 may further include a selectable option (e.g., parcel 502) to re-display the aggregated view containing the parcel displayed at block 1002. . Thereafter, processing may return to block 1004, where another partition selection may be received.

  FIG. 11 illustrates an example interface 1100 that may be displayed in response to a user rotating the user device 110 to a landscape view. In this orientation, the user device 110 may display an expanded view of a smaller subset of partitions than those displayed in the aggregated view of the interface 400. For example, interface 1100 may include an expanded view 1102 of section 408, an expanded view 1104 of section 406, and an expanded view 1106 of section 412. In the illustrated embodiment, the expanded view of the compartment may include a graphical representation of health data over various lengths of time. This allows the user to browse through the displayed types of health data to see how they change with respect to each other over time, and that changes in one type of health data You will be able to evaluate 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 whether the drug has a beneficial or detrimental effect. In some embodiments, the user device 110 may select a type of health data to be displayed when the user device 110 is rotated in the landscape orientation. The 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 possibly having a correlation may be displayed. Types of health data that are not displayed in the initial display of interface 1100 may be displayed by scrolling within the compartment. Further, partitions may be selected in the same manner as performed in interface 400 to display more detailed information.

  FIG. 12 illustrates an exemplary process 1200 for displaying health data based on device orientation, according to various embodiments. At block 1202, an aggregated view including a plurality of 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. You may. These compartments may include an identifier for the type of health data displayed on the compartment, and a partial view (e.g., summary, example, etc.) of some of the types of health data associated with the compartment. For example, an interface similar or identical to interface 400 may be displayed, including various health data sections 402, 404, 406, 408, 410, and 412.

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

  At block 1206, a subset of the plurality of partitions displayed at block 1202 may be selected for display. In some embodiments, the subset may be a predetermined subset of a plurality of partitions. In another embodiment, the subset may be selected based on a user-defined display setting. In still other embodiments, a subset of the plurality of parcels may be combined with a health data set associated with each parcel to determine whether any of the types of health data may be correlated. The selection may be 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 partitions selected in block 1206 may be displayed. In some embodiments, the identifier for the type of health data, displayed on the expanded view and / or summary of the parcel, example, or other view of the type of health data associated with the parcel, is block 1202. May be different from the one displayed on the section. For example, data for a summary or example on each expanded view may be replaced with a graphical representation of health data over time, as shown in FIG. Thereby, the relationship between the types of displayed health data can 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 a portrait orientation.

  As described above, in some embodiments, a user of the user device 110 may be authorized to access other users' health data. In these embodiments, user device 110 may allow a user to view other users' health data in a format similar to that described above in connection with FIGS. For example, as shown in the interface 1300 of FIG. 13, the user scrolls sideways through the content of the interface in the direction 1306 to view the health data of another user, and then views the first section of the parcel from the first user. May be displayed in place of the second set of partitions 1302 from the second user. In particular, a second set of compartments 1302 for a second user may be translated in a scrolling direction 1306 so that they disappear from the display, and the first plurality of compartments 1304 are moved in the same direction 1306 of the display. It may be translated from the other side onto the display. It should be understood that FIG. 13 shows a transition state in which section 1302 has been deleted from the display and section 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 displayed. As parcels 1302 and 1304 continue to scroll in direction 1306, parcel 1302 is completely removed from the display, and a smaller portion of parcel 1302 is displayed until parcel 1304 occupies all or most of the display. A larger portion may be displayed. Although not shown, the top section of section 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 through the parcels for all users that the user of device 110 is authorized to access.

  FIG. 14 illustrates another exemplary interface 1400 for displaying other user's health data. In some embodiments, interface 1400 may be displayed in response to selection of button 401 of interface 400. As shown, interface 1400 may include a list 1402, 1404, 1406, and 1408 of users who have authorized their users of user device 110 to access their health data. In some embodiments, 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 other 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 may indicate the level of authorization to display other users' health data, as described above. For example, a user in the "Family" category may have authorized a larger set of health data to be viewed, and a user in the "Friends" category may have authorized a smaller set of health data to be viewed. It may be. In response to selecting one of the users 1402, 1404, 1406, and 1408, the section 1410 may be updated to reflect the selected user's health data. This updates the types of health data displayed on the parcels (e.g., based on the types of health data that other users have authorized the user of the user device 110 to view) and associated with them. , Updating partial views (eg, summaries, examples, etc.) of some of the health data. In other embodiments, lists 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 illustrates an example process 1500 for displaying health data associated with two or more users according to various embodiments. At block 1502, a display of a first plurality of partitions associated with a first user may be displayed. These parcels may be similar or the same as parcels 402, 404, 406, 408, 410, and 412, and may be displayed by the same or the same user device as user device 110. These compartments may include an identifier for the type of health data displayed on the compartment, and a partial view (e.g., summary, example, etc.) of some of the types of health data associated with the compartment. For example, an interface similar or identical to interface 400 may be displayed, including various health data sections 402, 404, 406, 408, 410, and 412.

  At block 1504, a request to view a second user's second plurality of parcels 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 a user input for scrolling the display of the first plurality of partitions displayed at block 1502, rotating a mouse wheel, arrow keys on a keyboard, a touch-sensitive display. May be received by the user device in the form of a touch and / or swipe. Similar to the embodiment shown in FIG. 13, the scroll direction may be horizontal with respect to the content of the display and perpendicular to the scroll direction in which an additional section associated with the first user is displayed. 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 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 partitions displayed in block 1502 to display a list of users. Is also good. 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 display of a second plurality of partitions associated with the second user may be displayed. In some embodiments, if the request to view the second plurality of partitions received at block 1504 includes a request to scroll the display of the first plurality of partitions, FIG. , The first plurality of compartments may be translated in the direction of scrolling so as to disappear from the display, and the second plurality of compartments may be moved 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 parcels received at block 1504 included a selection of a second user from a list of users, as shown in FIG. , The first plurality of sections may be replaced with a display of the second plurality of sections. Viewing other user's health data compartments to display some or all of the set of compartments associated with the user that 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 understood that the processes described above may be combined. For example, process 1200 may be combined with process 1000 such that after multiple partitions are displayed in block 1002, blocks 1204, 1206, and 1208 are performed in response to a change in user device orientation. Similarly, after the plurality of parcels are displayed at block 1002, the process 1500 may respond to receiving a request to view the parcels associated with another user, and then selecting the plurality of parcels associated with another user. 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 follows. 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. You may. For example, a device performing the process 1000, 1200, or 1500 may update updated health or non-health data from the health database 111 or user database 116 continuously, intermittently, periodically, or any other desired. May be received at a frequency or time interval. In some embodiments, the device performing the process 1000, 1200, or 1500 may receive updates to all health or non-health data at the same frequency or time interval. In other embodiments, a device performing the process 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 basis. These intervals and frequencies may be default values or may be selected by the user.

  One or more of the functions related to the aggregation and sharing of health data may be performed by a system similar or the same as system 1600 shown in FIG. System 1600 may include instructions stored on non-transitory computer readable storage media, such as memory 1604 or storage device 1602, and executed by processor 1606. The instructions may also include an instruction execution system, apparatus, or system, such as a computer-based system, a system that includes a processor, or other system that can fetch instructions from, and execute, the instruction execution system, apparatus, or device. It may be stored and / or transmitted on any non-transitory computer readable storage medium for use by or with devices. In the context of this specification, a "non-transitory computer readable storage medium" is any medium that can contain or store a program for use by or with an instruction execution system, apparatus, or device. Is also good. Non-transitory computer-readable storage media include, but are not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, a portable computer diskette (magnetic), a random access memory (RAM), and the like. ), 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 (registered trademark) card, a secure digital card, a USB memory device, or a memory stick.

  The instructions may also include an instruction execution system, apparatus, or system, such as a computer-based system, a system including a processor, or other system that can fetch instructions from and execute the instructions from the instruction execution system, apparatus, or device. 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 that can transmit, propagate, or transmit programs for use with or with an instruction execution system, apparatus, or device. . Transmission media can include, but is not limited to, electronic, magnetic, optical, electromagnetic, or infrared wired or wireless propagation media.

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

  While the present disclosure and embodiments 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 as being included within the scope of the present disclosure and embodiments as defined by the appended claims.

Claims (9)

The method
In electronic devices,
A you to view a plurality of compartments containing a portion of the health data of the type associated said the identifier of the type of health data associated, each compartment health of a plurality of types of said plurality of compartments Being associated with one type of health data of the data;
In response to detecting a change in the orientation of the electronic device ,
For a subset of the plurality of compartments, replacing the display of the portion of the associated type of health data with a graphical representation of the health data;
And to view the previous Kisa subset of said plurality of compartments,
Including, methods. The change in orientation of the electronic device, the gyroscope of the electronic device, the accelerometer of the electronic device, or is detected on the basis of data from at least one of these combinations, the method according to claim 1 . 3. The method of claim 1 or 2, wherein detecting the change in the orientation of the electronic device comprises detecting a change in a threshold amount in the orientation of the electronic device.   4. The method of any preceding claim, wherein each of the displayed subsets of the plurality of compartments includes a graphical representation of at least a portion of the associated type of health data displayed therewith. Method.   Responding to detecting a change in the orientation of the electronic device,
    Selecting a subset of the plurality of compartments
  The method according to claim 1, further comprising: Selecting a subset of the plurality of compartments comprises:
Identifying a correlation between the plurality of types of health data;
5. The method of claim 4 , comprising: selecting a section associated with a correlated type of health data as the subset of the plurality of sections. An electronic device,
A memory storing one or more computer programs containing instructions for performing the method according to any one of claims 1 to 6 ,
One or more processors capable of executing the instructions stored in the memory;
Electronic devices, including. Computer program comprising instructions for performing the method according to any one of claims 1-6. An electronic device comprising means for performing the method according to any one of claims 1 to 6 according to a computer program.

Images