WO2010103428A1

WO2010103428A1 - Configurable hub

Info

Publication number: WO2010103428A1
Application number: PCT/IB2010/050907
Authority: WO
Inventors: Frank Wartena; Johan Muskens
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2009-03-11
Filing date: 2010-03-03
Publication date: 2010-09-16

Abstract

A device comprises a receiver, a storage device, a processor and a transmitter. The receiver is arranged to receive sensing data from one or more sensing devices. The storage device stores configuration information which defines one or more sensing data criteria and a respective action for each criteria. The processor accesses the configuration information and subdivides the received sensing data according to each criteria in the configuration information. The transmitter is arranged to transmit one or more sensing data subdivisions to a respective location, if the defined action for the relevant criteria is to transmit the sensing data subdivision.

Description

Configurable hub

FIELD OF THE INVENTION

This invention relates to a device and to a method of operating the device. In one embodiment, the device can be used as a configurable hub for a personal telehealth system.

BACKGROUND OF THE INVENTION

Initiatives such as the Continua Health Alliance have the ambition to change the existing healthcare system by enabling an interoperable telehealth eco system. Telehealth is the delivery of health-related services and information via telecommunications technologies. Within this type of personal telehealth system, health data is collected by the person and often aggregated on a telehealth hub, such as a mobile phone, PC, set-top box, or specialized telehealth aggregator. This data then needs to be sent to one or more health related services which are often Internet based services.

In addition, Google and Microsoft are creating personal health record platforms that can be used to deliver telehealth services. Google has opened the doors of

Google Health for anyone to sign up. Microsoft has launched HealthVault and allows anyone from the United States (extending to Europe soon) to sign up. This means two major companies are entering the domain of personal health records (PHRs). These systems enable people to maintain their own PHR and are designed to put the user in control of their own health data. The functionality offered covers the following aspects of telehealth, the ability to collect, store and share health data.

These technologies have the ambition to offer a platform that enables a system of health services and applications that are sharing and reusing health data. Health service providers can leverage the common infrastructure, but are facing the challenge of how to use the data that is collected in such a system that is not fully under the control of the health service provider, which is more of an issue for healthcare services such as remote patient monitoring and patient management than for fitness services. In order to do proper reasoning and take medical decisions the data used must be of sufficient and high quality. Similarly, the Continua Health Alliance also has the ambition to enable a personal telehealth eco system that allows multi vendor solutions.

Traditional personal telehealth systems were proprietary systems consisting of one or more measurement devices used by the patient, a single telehealth hub and a single backend service. The configuration was straightforward as all health information gathered by the measurement devices was received by the single telehealth hub and forwarded to the single backend service. The interoperability which the Continua Health Alliance is currently enabling will open up this proprietary model and enable multiple telehealth hubs to communicate with multiple backend service providers. New PHR platform initiatives like Google Health and Microsoft Health Vault would like to be the only recipient of health information and then distribute the information further to various services. However, it is rather unlikely that that will become reality as there will always be Internet services that want to receive the health data directly from the source without Google or Microsoft acting as the gatekeeper in the chain. Google or Microsoft can certainly be one of the receivers of the health information for example as a personal health record service. For example the current connection centre that forms part of the Microsoft HealthVault will forward all information to one Service (the HealthVault). The only thing that can be configured is the actual record all the data goes into.

SUMMARY OF THE INVENTION

It is therefore an object of the invention to improve upon the known art. According to a first aspect of the present invention, there is provided a device comprising a receiver arranged to receive sensing data from one or more sensing devices, a storage device arranged to store configuration information, the configuration information defining one or more sensing data criteria and a respective action for the or each criteria, a processor arranged to access the configuration information, and to subdivide the received sensing data according to the or each criteria in the configuration information, and a transmitter arranged to transmit one or more sensing data subdivisions to a respective location, if the defined action for the relevant criteria is to transmit the sensing data subdivision.

According to a second aspect of the present invention, there is provided a method of operating a device comprising receiving sensing data from one or more sensing devices, storing configuration information, the configuration information defining one or more sensing data criteria and a respective action for the or each criteria, accessing the configuration information, subdividing the received sensing data according to the or each criteria in the configuration information, and transmitting one or more sensing data subdivisions to a respective location, if the defined action for the relevant criteria is to transmit the sensing data subdivision. According to a third aspect of the present invention, there is provided a computer program product on a computer readable medium for operating a device, the product comprising instructions for receiving sensing data from one or more sensing devices, storing configuration information, the configuration information defining one or more sensing data criteria and a respective action for the or each criteria, accessing the configuration information, subdividing the received sensing data according to the or each criteria in the configuration information, and transmitting one or more sensing data subdivisions to a respective location, if the defined action for the relevant criteria is to transmit the sensing data subdivision.

Owing to the invention, it is possible to provide an approach for configuring a device (the telehealth hub) to transfer the health data to one or more service providers based on adaptable criteria. This allows the user to control which health data goes to which service providers, based on for example, personal preference (such as privacy considerations) and the needs of the services and service providers. Therefore there is provided a configuration mechanism that allows the user to control where the device (the telehealth hub) transfers the gathered health data. In order to give the patient control over where their health data is transferred it is now possible to properly configure the telehealth hub to transfer specific subsets of health data to specific backend services.

The device, which acts as the telehealth hub, provides a configurable set of criteria which determines the subsets of health data that are intended for each of the receiving services and service providers. The user is able to configure the criteria for each service and specify what should be done with the health data, for example transfer directly to the service (which can be the default option), store on the telehealth hub, or aggregate with other data before transferring to the service provider, etc.

Preferably, the configuration information further defines a combination of sensing data criteria and a corresponding action for the combination of criteria. An individual criteria, such as all measurements from a sensor A, can be used to define a subset of the received sensing data, can also be combined with a different criteria, such as maximum daily reading, to create an additional or alternative subset of the received sensing data. This allows the device (the hub) to provide a high level of flexibility in relation to the functions that are offered by the sensing devices and allows the user and/or the service providers to define subsets of the data input that are appropriate for the telehealth function being delivered. The amount of data traffic is reduced and each service or service provider can define with a high level of specificity the exact data required. Advantageously, the configuration information further includes one or more priorities attached to respective actions, and the processor is arranged to ensure performance of the respective actions in the order of the priorities. The configuration information can be so defined so that it is possible to order the criteria (or criteria combinations) according to priority. For example, if the user has a heart condition, then a subset defined by a criteria relating to a measured heart rate above a predefined level, can be handled first, thereby alerting a remote health service provider, before other subsets defined by different criteria such as storage of the measured data.

Ideally the processor is further arranged to perform the respective action for a criteria, if the defined action for the relevant criteria is not a transmission action. Other actions which may be defined for the criteria such as storage or aggregation can be handled by the device's processor without needing to transmit the information to any remote service, thereby increasing the usefulness of the hub and also ensuring that maximum flexibility is delivered in terms of the options available for the handling of the different subsets.

Preferably, the device further comprises a user interface arranged to receive user input, the processor defining or adapting the configuration information in response to the user input. The hub preferably includes a user interface so that the user can amend or create new criteria or actions relative to existing criteria (or criteria combinations). This allows the user to derive the maximum functionality from the hub and also ensures that the hub can be updated to reflect changing circumstances relative to the patient.

BRIEF DESCRIPTION OF THE EMBODIMENTS

Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:-

Fig. 1 is a schematic diagram of a telehealth system, Figs. 2 and 3 are schematic diagrams of configuration information,

Fig. 4 is a further schematic diagram of the telehealth system showing detail of a hub device,

Fig. 5 is a schematic diagram showing processing of sensing data, and

Fig. 6 is a flowchart of a method of operating the hub device. DETAILED DESCRIPTION OF THE DRAWINGS

Fig. 1 illustrates schematically an example of a telehealth system, which comprises various sensing devices 10 which connect to a hub device 12. The hub device 12 connects to multiple services 14 via the Internet 16. The nature of a telehealth system is that health care services are delivered to a patient who is remote from the actual service provider. The sensing devices 10 and the hub device 12 are located in the user's home, and the various services 14 are located remotely from the home. The sensing devices shown are a blood pressure monitor 10a, a gluco meter 10b and a weighing scale 10c, all of which have communication with the hub device 12. Through the Internet 16, the hub device 12 connects to a weight loss service 14a, a diabetes service 14b and a personal health record service 14c.

The telehealth hub device 12 is the aggregator of health information located near the person. The hub device 12 can take the form of a mobile phone, PC, set-top box, or specialized telehealth aggregator device, etc. Now that telehealth hub devices 12 are becoming interoperable, for example through the standardization efforts of the Continua

Health Alliance, every hub device 12 will be able to communicate with one or more services 14. A central role for the telehealth hub device 12 is to coordinate which health information goes to which service 14. This coordination needs to be under the control of the user and the configuration can change over time, for example if a user deregisters from a service 14 or if a user buys a new measurement device 10.

The telehealth hub device 12 will receive measurements of vital signs such as weight, blood pressure, heart rate, glucose level, etc. from the sensing devices 10. Not all of these measurements are relevant for all of the services 14, and moreover the person might not want all of the measurements to be shared with all of the services, for example because the user trusts one service 14 more than another. Therefore, in order to reflect these considerations of the user, the telehealth hub device 12 will need to be configured to transfer the appropriate health information to each of the services with which the user would like to share the information.

The essential part of the telehealth system is that the hub device 12 uses a configurable set of criteria to create subsets of health information that should be shared with the services 14. Fig. 2 shows an example of configuration information 18 which is used to configure the hub device 12. As a general principle, the configuration information 18 comprises one or more sensing data criteria 20 and a respective action 22 for each of the criteria 20. In the example of Fig. 2, each of the actions 22 is a location, and so the default action 22 is to send the relevant data subset to that location as soon as possible.

The type of things that can be used as criteria 20 include the type of health information (e.g. blood pressure, weight, glucose level), the specific device 10 that was used to acquire the health information (e.g. a disease management service might only need the measurements from a specific weight scale and not all weight measurements), the time the measurement was taken (that same disease management service might only need weight measurements that were done in the morning and not weight measurements done during the day), and if the measurement was done before or after a specific event (e.g. before or after breakfast). The example criteria 20 can be extended to include anything that can be used to subdivide the received data from the sensing devices 10.

In the example of Fig. 2, the different criteria 20 are all based upon the nature of the relevant sensing data, regardless of the original device 10 that actually acquired the data. The first criteria 20a relates to all of the measurements of the weight of the user (whether made by the weighing scale 10c or not), and the respective action 22a is to send that sensing data to the weight loss service 14a. The second criteria 20b defines the blood pressure and glucose measurements, and the respective action 22b is to send this sensing data to the diabetes service 14b. The third criteria 20c relates to all three of the data types made by the devices 10, and the respective action 22c is to send all of that sensing data to the personal health record service 14c.

It is also possible to use a combination of the criteria 20 to create a subset, for example by only considering certain types of measurements in a specific time window on the day. In this case, the configuration information 18 further defines a combination of sensing data criteria 20 and a corresponding action 22 for the combination of criteria 20. This can be seen in Fig. 3, where the first criteria 20 is made up of a combination of two different criteria CIa and CIb. These define, firstly the type of measurement, being the weight of the user, and then secondly the first measurement of the day. This means that only the first weight measurement of the day will be transferred to the weight loss service 14a. The subset function is defined that creates a subset of observations O' out of the elements o in the whole set of observations O that satisfy the criteria C. O' = subset (O,C), where O' = { o in O| o satisfies C }. For each of the services 14, the telehealth hub device 12 will have a set of criteria 20 that defines which subset of the total health information received by the hub device 12, should be transferred to that service 14. Upon receipt of a new measurement from one of the measurement devices 10, the telehealth hub device 12 will determine, based on the criteria 20, to which services 14 this measurement should be transferred.

In addition, or alternatively, to directly transferring the health information to the appropriate services 14, there are also other actions that can be taken by the hub device 12. For example, a certain service 14 might only need to receive new measurements once per day, so all of the measurements that should be transferred to that service 14 will first be temporarily stored on the telehealth hub device 12, and only at the specified moment all stored measurements will be transferred at once. Effectively, the hub device 12 will act as an aggregator of information received from one or more sensing devices 10. The hub device 12 stores the information received locally until it is needed to be sent to the relevant service 14.

Fig. 4 shows more details of the internal components of the hub device 12. The device 12 is provided with a receiver 24, which is arranged to receive various sensing data from the sensing devices 10 and a transmitter 26 arranged to transmit the sensing data subdivisions to specified locations 14, when the defined action 22 for the relevant criteria 20 is to transmit the sensing data subdivision. This, of course, is defined within the configuration information 18. A storage device 30 stores the configuration information 18. The device 12 also includes a processor 28 which accesses the configuration information 18 and subdivides the received sensing data according to the criteria 20 in the configuration information 18.

In order to properly configure the telehealth hub device 12, the user will need to indicate on the telehealth hub device 12 which services 14 should receive which health information and also the actions (send directly, aggregate first and send later, etc.) which should be performed for the health information that meets the specified criteria 20 for each of those services 14. This means that for each service 14 there is a list of (criteria, action) tuples, contained within the configuration information 18. The configuration information 18 defines one or more sensing data criteria 20 and a respective action 22 for each criteria 20. The user can input this information directly via user interface 32 which can be a touchscreen display, for example.

In order to make this configuration easier for the user, each service 14 could also offer a configuration script. When the user indicates on the telehealth hub device 12 which service 14 they would like to add, the telehealth hub device 12 can contact that service 14 via the Internet connection and download the configuration information 18 (the specific criteria 20 and actions 22) including mandatory items (for example that the service 14 cannot operate without receiving weight data) and optional items (for example that the service 14 might offer a better experience if it also receives blood pressure data). The user can then decide to accept or decline those configuration items and also indicate if they want to include the optional items.

Other methods of configuring the hub device 12 are also possible. For example, a user may access a web-based interface provided by the telehealth hub that can be accessed from a conventional PC, similar to how current broadband modems can be configured. Another method of achieving the configuration is for the user to be provided with some additional device such as a USB key, for example when they visit their health professional or purchase the hub device 12, which stores a configuration file that will be used to configure the device 12 when the key is brought into contact with the hub device 12 by the user.

Fig. 5 shows schematically the processing of received sensing data 34 at the hub device 12. In the example of this Fig., two sensing devices 10 have provided sensing data 34. The first device 10 is a weighing device 10, and the user has weighed themselves at three different times during a particular day. At 9am they weighed 90kg, at lpm they weighed 94 kg and at 4pm they weighed 92 kg. The second sensing device 10 is a heart rate monitor 10, which the user has used twice to measure their heart rate. At 9am their heart rate was 100 bpm, and at 6pm their heart rate was 122 bpm.

The sensing data 34 is processed by the processor 28 of the hub device 12, according to the configuration information 18. The effect of this processing is to subdivide the data 34 into separate sensing data subdivisions 36. Note that individual data portions 34 can be separated into more than one subdivision 36. Each subdivision 36 corresponds to a criteria 20 (or criteria combination) within the configuration information 18. From left to right in the Fig., the subdivisions 36 correspond to criteria "sensor 1 and first measurement of the day", "all sensor data" and "sensor 2 and over 120 bpm". The subdivisions 36 are fluid and will not always exist if no data 34 matches the necessary criteria 20 (or criteria combination) from the configuration information 18.

As discussed above, each criteria 20 (or criteria combination) has an associated action 22. The details of the specific actions 22 are contained within the configuration information 18. In this example, the actions 22 are matched to the subdivisions 36 to illustrate the effect of the configuration information 18 as processed by the device hub 12. The first action 22 is to send as soon as possible the content of subdivision 36 to the service one. This action 22 has a priority (high) attached to it, which means that the hub device 12 must process this action 22 first. The second action 22 is to aggregate the data in the relevant subdivision 36 and send it to service two at the end of the day. The third action 22 is to provide an alert to the user when there is a data portion 34 in the specific subdivision 36.

The method of operating the hub device 12 is summarized in Fig. 6, and comprises the steps shown in this Fig. Step Sl comprises receiving the sensing data 34 from one or more of the sensing devices 10 and step S2 comprises storing the configuration information 18. As discussed above, the configuration information 18 defines one or more sensing data criteria 20 and a respective action 22 for each criteria 20. The hub device 12 has permanent access to the configuration information 18, which is stored locally on the device 12. The configuration information 18 can be changed by the user at any time, if they so desire. The user can also allow access to the device 12 from third parties such as a service provider 14, for the purpose of adapting the configuration information 18.

The next step in the method is the step S3 of accessing the configuration information 18, followed by the step S4 of subdividing the received sensing data 34 according to each criteria 20 in the configuration information 18. The final step S5 is the step of transmitting one or more sensing data subdivisions 36 to a respective location 14, if the defined action 22 for the relevant criteria 20 is to transmit the sensing data subdivision 36. The default action 22 is always to transmit the relevant sensing data 34, and the action 22 may just comprise the location 22 to which the data 34 should be sent. Of course, other actions 22 may be carried in addition or alternatively to the transmission of the data 34 to a service 14.

All of the method steps shown in Fig. 6 can be carried out in software, in which case a computer program product on a computer readable medium such as a CD-ROM can be provided that will control the processor 28 of the hub device 12.

There are applications of the system including the improved hub device 12 in the area of health and fitness and personal disease management. In use, the interoperable telehealth hub device 12 can be configured on which health information is transferred to which services. Using the criteria 20 as documented above will provide control to the user on the configuration of the device 12 and will ensure that the services 14 receive the appropriate information 34 without compromising the privacy of the user. The approach can enable the building of telehealth hub devices 12 (set-top boxes, phones, etc) that operate in a telehealth system where users have a single infrastructure at home and have subscriptions on multiple telehealth services 14, with the work of distributing the correct information to the correct service 14 being carried out by the hub device 12.

Claims

CLAIMS:

1. A device (12) comprising: a receiver (24) arranged to receive sensing data (34) from one or more sensing devices (10), a storage device (30) arranged to store configuration information (18), the configuration information (18) defining one or more sensing data criteria (20) and a respective action (22) for the or each criteria (20), a processor (28) arranged to access the configuration information (18), and to subdivide the received sensing data (34) according to the or each criteria (20) in the configuration information (18), and - a transmitter (26) arranged to transmit one or more sensing data subdivisions

(36) to a respective location (14), if the defined action (22) for the relevant criteria (20) is to transmit the sensing data subdivision (36).

2. A device according to claim 1, wherein the configuration information (18) further defines a combination of sensing data criteria (20) and a corresponding action (22) for the combination of criteria (20).

3. A device according to claim 1 or 2, wherein the configuration information (18) further includes one or more priorities attached to respective actions (22), and the processor (28) is arranged to ensure performance of the respective actions (22) in the order of the priorities.

4. A device according to claim 1, 2 or 3, wherein the processor (28) is further arranged to perform the respective action (22) for a criteria (20), if the defined action (22) for the relevant criteria (20) is not a transmission action (22).

5. A device according to any preceding claim, and further comprising a user interface (32) arranged to receive user input, the processor (28) defining or adapting the configuration information (18) in response to the user input.

6. A method of operating a device (12) comprising: receiving sensing data (34) from one or more sensing devices (10), storing configuration information (18), the configuration information (18) defining one or more sensing data criteria (20) and a respective action (22) for the or each criteria (20), accessing the configuration information (18), subdividing the received sensing data (34) according to the or each criteria (20) in the configuration information (18), and - transmitting one or more sensing data subdivisions (36) to a respective location (14), if the defined action (22) for the relevant criteria (20) is to transmit the sensing data subdivision (36).

7. A method according to claim 6, wherein the configuration information (18) further defines a combination of sensing data criteria (20) and a corresponding action (22) for the combination of criteria (20).

8. A method according to claim 6 or 7, wherein the configuration information (18) further includes one or more priorities attached to respective actions (22), and the method comprises performance of the respective actions (22) in the order of the priorities.

9. A method according to claim 6, 7 or 8, and further comprising receiving a user input and defining or adapting the configuration information (18) in response to the user input.

10. A computer program product on a computer readable medium for operating a device (12), the product comprising instructions for: receiving sensing data (34) from one or more sensing devices (10), storing configuration information (18), the configuration information (18) defining one or more sensing data criteria (20) and a respective action (22) for the or each criteria (20), accessing the configuration information (18), subdividing the received sensing data (34) according to the or each criteria (20) in the configuration information (18), and transmitting one or more sensing data subdivisions (36) to a respective location (14), if the defined action (22) for the relevant criteria (20) is to transmit the sensing data subdivision (36).