INTERFACE DEVICE

Field of the Invention

This invention relates to an interface device for a health monitoring system and a system for monitoring health of an individual.

Background to the Invention

An individual (that is, a person) may monitor various parameters indicative of his or her own health using a health monitoring device. An example of a health monitoring device is a glucose monitor, which provides a reading of the level of glucose in the individual's blood when the individual uses the glucose monitor.

In the UK, there are approximately 1.5 million diabetics. Diabetics occupy around 10% of hospital beds and contribute to around £2 billion of health expenditure each year. The usage of hospital beds and the health expenditure arises mainly from complications due to the diabetic condition.

Summary of the Invention

According to a first aspect of the invention, there is provided an interface apparatus comprising at least one of: a first interface for receiving data from a medical device; and a second interface for providing data to a wireless communications device such that one or more wireless communications indicating the data can be transmitted to a destination.

Thus, the interface can be used to allow the data provided by the data device to be sent wirelessly to the destination using the portable communications device, even where the data device itself is not capable of communicating (wirelessly or otherwise) with the destination. A user of the data device may own or use the portable communications device for other purposes (such as personal communications of the user), and thus the infrastructure for transmitting the data to the destination may already exist. Thus, embodiments of the invention can

provide a low-cost solution to enabling the wireless transmission of data from the data device to the destination. Furthermore, in embodiments of the invention at least one of the portable wireless communications device and the data device does not require any extra hardware and/or software to operate with embodiments of the invention.

In certain embodiments, at least one of the first and second interfaces comprises a serial interface. Preferably, the second interface comprises a short-range wireless communications link for providing the data to the portable wireless communications device. The communications device may be arranged to communicate the data on to a further destination using longer-range wireless communications, such as a wireless telephone network. Therefore, the portable wireless communications device can be used by embodiments of the invention without requiring a wired connection, which provides ease of use for a user. The short-range wireless communications module may comprise a Bluetooth™ module for providing the data to the portable wireless communications device using Bluetooth™ communications. Bluetooth™ is a standard specification for wireless communications (see, for example, http://www.bluetooth.com/NR/rdonlyres/lF6469BA-6AE7-42B6-B5A l- 65148B9DB238/840/Core_v210_EDR.zip for the Bluetooth™ core specification version 2.0 or subsequent versions, the contents of which are incorporated herein by reference for all purposes). Alternatively Wibree or Zigbee® communications, or other suitable short range wireless communications standards can be used. Using a standard specification allows the use of existing technologies and components, leading to high reliability and/or low cost.

In certain embodiments, the data device comprises an individual health monitoring device. Therefore, for example, the data may comprise values of one or more parameters indicative of the status of the individual's health. For example, the data device may comprise a glucose monitor, and the data may

comprise one or more readings of the individual's blood glucose concentration. The destination can, therefore, monitor the individual's health remotely.

In certain embodiments, the portable wireless communications device transmits the data to the destination within one or more short message service (SMS) messages. Therefore, an existing form of communications can be used to transmit the data, thus leading to a reliable and/or low cost implementation.

According to a second aspect of the invention, there is provided a system for monitoring health of an individual, comprising: a medical data device for providing medical data indicative of the health of the individual; a wireless communications device; interface apparatus comprising a first interface for receiving the medical data from the medical data device and a second interface for providing the data to the wireless communications device; and health monitoring apparatus for receiving one or more wireless communications from the wireless communications device containing the medical data. The data may be individual readings which, when analysed as a set, indicate the health of the individual. Means for storage, retrieval and presentation of the data set may be provided, for example using a web-server and database. The data including results of analyses may be presented in graphical or tabular form. The system may be capable of sending alerts to users (patients, clinicians or other person). e.g. via SMS text messages or e-mails.

The interface apparatus may comprise a separate unit which can be connected to the medical data device, for example by a wired connection. Alternatively it may be formed integrally with the medical data device as a single unit.

Thus, the system may be used to remotely monitor the health of the individual.

In certain embodiments, the system comprises an alert system for alerting a user (normally clinician but it could be the patient or someone else) when one or more of the communications indicates that one or more measured parameters meet a

condition indicating that the health of the individual is abnormal. Therefore, for example, a user of the system is only alerted to abnormal data and can act accordingly, and may not be alerted to normal data that requires no action to be taken. Additionally or alternatively, the alert system may alert the user when a wireless communication of data indicating the health of the individual has not been received for some time. This alert may be in the form of an SMS to the patient and/or e-mail to the patient or clinician and/or web-page report.

According to a third aspect of the invention, there is provided a method of monitoring health of an individual, comprising receiving data from a data device, the data indicating the health of the individual; and providing the data to a portable wireless communications device for communicating the data wirelessly to a destination.

The method of the invention may include any of the steps which the device or the system of the invention is arranged to perform. The device and system may be arranged to perform any of the steps of the method of the invention.

Embodiments of the invention will now be described by way of example only, with reference to the accompanying drawings.

Brief Description of the Drawings

Figure 1 shows a system for monitoring the health of an individual according to an embodiment of the invention;

Figure 2 shows an interface device forming part of the system of Figure 1 ;

Figures 3a, 3b and 3c shows operation of the logic core of the interface device of Figure 2 in more detail; and

Figure 4 shows a server and data processing system forming part of the system of Figure 1.

Detailed Description of Embodiments of the Invention

The system 100 of Figure 1 comprises a data device 102. The data device 102 is a device that obtains and/or generates data. The data device 102 may comprise, for example, a device for monitoring one or more parameters relating to the health of an individual. Thus, the data relates to such parameters, and may be one or more values of the parameters recorded at different times, and may also include a time code indicating the time at which each value was recorded. The device 102 for monitoring the health of the individual may comprise, for example, a glucose monitor that monitors the level of glucose in the individual's blood. Such a device may be used by diabetics, for example, to monitor their blood glucose level and therefore their health in terms of blood glucose level. The data may therefore comprise data indicating the blood glucose level of the individual and/or data that indicates the health of the individual in terms of blood glucose level.

The system 100 also includes a communications device 104. The communications device 104, which may be portable, is a device that can communicate wirelessly with a destination, for example by sending one or more communications to the destination and/or receiving one or more communications from the destination. The portable communications device 104 may be a mobile phone, PDA, portable or laptop computer and other personal communication devices. Using such a personal communications device may allow use of wireless functionality of the communications device to transmit data to a destination. The personal communications device 104 may be associated with, for example, a subscription or contract that allows a user to use the communications device for personal communications. Embodiments of the invention may use the services provided in the subscription or contract to

transmit data to the destination. Therefore, for example, embodiments of the invention may not need dedicated functionality for sending wireless communications to the destination and/or a specific subscription or contract, as the functionality and/or subscription or contract associated with the communications device may be used.

The system 100 further includes an interface device 106. The interface device 106 serves as an interface between the data device 102 and the communications device 104 such that data provided by the data device 102 can be transmitted to a destination by the communications device 104 using one or more wireless communications. For example, the interface device 102 receives data from the data device 102 and provides the data to the communications device 104 as part of a command sequence understood by the communications device 104 to send the data to a destination within one or more wireless communications.

A wireless communication is a communication that is transmitted between a source and a destination, where at least part of the transmission does not use a physical (wired) connection. Therefore, for example, a wireless communication can be transmitted to the destination over one or more wireless communications links, and also may be transmitted over one or more wired communication links. For example, where the communications device 104 is a mobile telephone, and the communications comprise one or more SMS messages, the SMS messages may be transmitted wirelessly to, for example, a base station 122, 124 of a mobile telephone network 126 associated with the mobile telephone. The SMS messages may then be transmitted using through the network 126 to the destination terminal 402.

The destination, which may form part of the overall system, may include a server

400 connected to a communications link, such as a GSM modem 402 which enables it to communicate over the network 126. The server 400 may include a number of features including providing reception for communications from, and

transmission of communications to, the communications device 104, for example in the form of SMS messages, a database of results i.e. measurements taken using the data device 102 for a number of patients/users. The server may also be arranged to provide a presentation interface, e.g. a web server, to enable presentation of the data stored in the database. The server 400 may also be connected to a network 404, such as a LAN or WAN to which a terminal 406, such as a clinician's PC, is also connected. This can enable the clinician to review the records stored on the server 400.

Referring to Figure 2, the interface device 106 comprises a first interface module 108 for interfacing with the data device 102. For example, the interface device 106 receives data from the data device 102 via the interface module 108. The data is provided to the interface module 108 by the data device 102 over a first interface link 110 that may be a wired and/or wireless communications link. In embodiments of the invention, the link 110 is a wired serial link, such that, for example, the interface device 106 is plugged directly into a port (not shown) on the data device 102 or a cable is connected between the data device 102 and the interface module 108. For example the interface module 108 may be an RS232 driver.

The interface device 106 also comprises a second interface module 112 for interfacing with the portable wireless communications device 104. For example, the interface device 106 may provide data to be transmitted to the portable wireless communications device 104 via the interface module over a wired and/or wireless communications link 114. In embodiments of the invention, the second interface module 112 is a Bluetooth™ modem connected to an integrated antenna 113, and the communications link 114 is a wireless communications link, such that data is provided to the communications device 104 using the Bluetooth™ communication standard.

As part of a setup procedure, which need only be performed once, the interface device 106 trigged by for example the user pressing and holding a button for a few seconds would initiate a sequence of Bluetooth™ communications to perform the Bluetooth™ "device discovery" and "pairing" operations. This involves the exchange of an authorisation code (or key) for further communications verified by entering a PIN number into the communications device 104 which is compared with the PIN programmed into the interface device 106. This is a necessary first step in Bluetooth™ communications performed by such devices and after a first manual, pairing may be made automatically.

The interface device 106 may then, using Bluetooth™ communications, establish a connection by "bonding" to the "serial port profile" of a Bluetooth™ enabled communications device 104 (for example a mobile telephone previously paired to the interface device). This provides a wireless channel over which commands and data may be communicated with the communications device. Using this channel the interface device 106 sends commands with or without data to instruct the communications device 104 to perform any required operations without the need for the user to operate the communications device directly.

The data may be provided by the interface device 106 to the communications device 104 in the form of a sequence of values forming part of a command packet transmitted over the Bluetooth wireless link and understood by the communications device 104. This command packet further includes details of the destination as well as the data to be sent. For example the packet may include a send-text-message-command together with destination, service, type-identifiers, packet-length and the data we wish to send converted to valid SMS alphabet. For example the command may be the ETSI GSM 07.05 specified "CMGS" command used to send an SMS text message to a given destination. The data may comprise one or more readings from the data device 102. The communications device 104 has its own protocol and interface (PDU) to allow

the interface device 106 to send it commands. For example there are a few hundred commands recognised by a GSM phone which can be used.

Thus, an interface device according to embodiments of the invention may interface with the data device and/or the portable wireless communications device without any modification to the data device or communications device to enable their use with the interface device. This may provide a high level of convenience for an individual that is using the data device to, for example, monitor their health. For example, the data device and the communications device will generally be provided with hardware and/or software as standard which are for communication, but not compatible for direct communication between the two. The interface device can therefore enable the data from the data device to be communicated to the communications device, without the need to modify either of them.

The device 106 comprises a logic core 200 that can communicate with the first and second interface modules 108, 112. It also comprises a power management unit 206 and a non-volatile memory 204. The logic core 200 may also retrieve data from and/or store data in the non-volatile memory 204. The non-volatile memory 204 may be used to store instructions for execution by the logic core 200 and/or data to be used by the logic core 200. The memory 204 is non- volatile such that when the device 106 is switched off, for example, the data within the memory 204 is retained. The logic core 200 and Bluetooth™ module 112 receive power from the power management unit 206 that includes one or more power sources 208 such as a battery. The power management unit 206 provides power to the logic core 200 and the Bluetooth™ module when they require power, i.e. when data is received from the data device 102 and is being provided to the portable wireless communications device 104 by the Bluetooth™ module 112. For example, when the device 106 is switched off, the power management unit 206 does not provide power to the logic core 200 and/or the Bluetooth module 112.

The logic core 200 may comprise, for example, a field programmable gate array (FPGA) or PLD (programmable logic device), or microcontroller or embedded microcontroller that can be programmed with appropriate logic and/or software to operate within a device according to embodiments of the invention. However, in other embodiments of the invention, other types of logic core may be used. Additionally or alternatively, the logic core 200 may comprise multiple logic devices. Additionally or alternatively, in embodiments of the invention the logic core 200 may contain some or all of one or more other components of the device 106 such as, for example, the power management unit 206, memory 204, interface module 108 and/or Bluetooth™ module 112. In embodiments of the invention, the logic core 200 and the Bluetooth™ module 112 include interfaces such that the logic core 200 can provide the Bluetooth™ module 112 with data, such as data to be transmitted to a destination. In the embodiment shown, the logic core 200 includes a universal asynchronous receiver/transmitter (UART) 240 arranged to communicate with the interfaces 108, 112 via a serial data switch 242.

The logic core 200 further may comprise a data bus 250 to which the UART 240 is connected, a non- volatile random access memory (NVRAM) interface 252, which serves as an interface between the data bus 250 and the non-volatile memory 204, an ASIP controller 254 with associated RAM 256, also connected to the data bus, an arithmetic logic unit (ALU) 258 also connected to the data bus, and an I/O register 260.

The interface device 106 further comprises a pushbutton switch 270 connected to the power management unit 206 to provide a user input to power up the device. The logic core 200 provides a power control output to configure the power management unit 206 to power-down the module 106. The interface device 106 further comprises a status indicator in the form of an LED array 272 which is controlled by the logic core 200 via the I/O register to indicate the status of the device.

The device 106 also has a configuration mode input port 274 which is connected to the I/O register 260 to enable configuration of the device. At such time a clinician's PC 280 is connected to the serial input 110 to allow configuration of the device, for example to update the ID of the devices with which the interface device 106 can communicate and set limits on what data the device 106 can communicate, or the format in which it is communicated. The device also has a diagnostics port 282. A clock oscillator 284 regulates the timing of the operations of the logic core 200.

The interface device 106 according to embodiments of the invention may be able to receive update data. For example, update data may be received via the interface module 108 and/or the Bluetooth™ module 112 shown in Figure 2. For example, update data may be sent to the portable wireless communications device 104, which passes the update data to the interface device 106 via the communication link 114 shown in Figure 1. The update data may be sent to the communications device 104, for example, when it is available, at an appropriate time and/or in response to a request from the interface device 106. The update data may include information for updating instructions in the memory 204. Additionally or alternatively, where the logic core 200 includes a programmable logic device (PLD), FPGA, microcontroller or similar device, the update data may include information for updating the logic within the logic core. Therefore, the interface device 106 may be updated, for example, to improve efficiency, support further data devices, add functionality or correct errors.

The operation of the glucose monitor 102 and interface device 106 according to one embodiment of the invention will now be described with reference to Figures 3a, 3b and 3c.

Referring to Figure 3a, when the patient wants to measure their blood glucose level they insert a test strip with a drop of blood on it into the glucose monitor

102 at step 502. The monitor calculates the glucose concentration in the blood at

step 504 and displays the concentration reading at step 506. On initial set-up of the system, the clinician will connect the interface device 106 to the monitor 102 at step 508. Normally this step will not be needed for each reading, but it will be performed before any readings are taken. When the patient has taken one or more readings, or the clinician has connected up the interface device 106, the push button 270 on the interface device 106 is pressed at step 510, which causes the board in the interface device to power up at step 512. The logic core 200 of the interface device 106 first checks at step 514 whether there is a configuration input at the configuration input port 274. If there is, then this indicates that the system is to be configured, or that the configuration is being checked. The logic core 200 therefore checks at step 516 the length of depression of the push button, which indicates the direction of transfer, i.e. whether the device 106 is being reconfigured, or its configuration being checked. The UART 240 is activated at step 518 and starts to transmit or receive serial bits at step 520. This is continued until a byte is detected as ready at step 522 at which point the byte is transferred to or from the NVRAM 204 at step 524. Then a check is made at step 526 to see if the push button 270 has been pressed again, or the configuration input disconnected. If neither of these has occurred, then the system returns to step 520 to continue with the data transfer. If one of them has occurred, then the power management system is instructed to power the interface device 106 off at step 528.

At step 514, if no configuration input is detected, then the controller 254 proceeds to run one of two programs, either a pairing program to pair the interface device 106 with any nearby Bluetooth™ devices, or a data transfer program to transfer data via the Bluetooth™ interface. To do this it transfers the contents of the NVRAM 204 to the main memory 256 at step 530, initialises a stack pointer in the controller 254 at step 532, and then checks at step 534 the duration of a press of the push button switch 270. If it detects that the press is long it initialises a program counter to the start of the pairing program at step 536, and if it detects a short press it initialises the program counter to the start of

the data transfer program at step 538. Once the appropriate program has been selected, the first instruction is fetched from memory and executed at step 540. A check is made whether this is a jump instruction at step 542, and if it is not, a check is made whether it is a halt instruction at step 544, and if it is not the program counter is incremented at step 546 and the system returns to step 540 to fetch the next instruction. If the instruction is a jump instruction then the new program counter value of the next instruction, which is the destination of the jump, is loaded at step 548 before returning to step 540 to fetch the next instruction. If at step 544 a halt instruction is detected, then execution of the program is complete and the retained registers in the main memory are transferred back to the NVRAM at step 550.

Referring to Figure 3b, the steps of the Bluetooth™ pairing program will now be described. At step 600 the UART 240 is activated and the Bluetooth™ port selected. Then at step 602 the Bluetooth™ modem 112 is powered up, and the controller 254 waits for the startup message from the Bluetooth™ modem 112 to arrive via the UART 240 at step 604. When that arrives, the pairing table is cleared at step 606, a Bluetooth™ device discovery command issued via the UART 240 at step 608, and all detected Bluetooth™ device IDs are transferred to memory at step 610. Then for each device ID, a bonding request with a PIN is sent out at step 612 and an OK' response waited for at step 614. If no OK responses are received from any of the devices, the red LED 272 is flashed at step 616 and the program halts. If an 'OK' response is received from one of the devices, then the ID is stored in memory at step 618 and the green LED flashed at step 620 and the program halts.

Referring to Figure 3c, the steps of the data transfer program will now be described. At step 700 a reading counter is initialised by being set to zero, the UART 240 is activated and the data device port selected at step 702. An initialisation string is sent to the data device 102 at step 704, which includes the ID of the data device which is expected to provide its readings, and a response

awaited. If the response indicates that the wrong data device is connected to the interface device 106 then an error is recorded. However, if the correct monitor response is received at step 706 then the controller 254 performs a series of steps for each record in the monitor's memory to transfer all un-sent monitor readings into a list for sending. At step 710 the record is retrieved from the monitor's memory. At step 712 the controller 254 checks whether the record is a serial number of a data device. If it is not, then the controller proceeds to step 714 where the record is checked to determine whether it is a glucose reading. If the record is a device serial number, then the serial number is checked at step 716 to see if it is a new monitor. If it is not, then the processor proceeds to step 714. If it is, then the last reading sent by the interface device 106 is set to zero at step 718 before proceeding to step 714. From step 714, if the record is not a glucose reading, then the cycle is repeated for the next record. If it is a glucose reading, then at step 720 it is checked to determine whether it is a new reading. If not, the cycle is repeated for the next record, but if it is, then the reading is added to the list of records to be transmitted at step 722 before the cycle is repeated for the next record.

Once all readings have been loaded from the glucose monitor 102, they are sent as one or more text message commands via the Bluetooth™ interface to the communications device 104. The Bluetooth™ port is selected at step 730, a connect command is sent to the Bluetooth™ module at step 732, and if the connection is accepted a text message header is sent at step 734, followed by readings from the stored list at step 736 up to the maximum number for one text message. Then when either all the readings have been sent, or the maximum number of readings for one text message has been sent, the command packet is finalized and the read response checked at step 738. If the message is sent successfully, then a check is made at step 740 whether there are more readings to send. If there are then a message continuation header is sent at step 742 followed by further readings from the list at step 736. When all the readings have been sent the record of the last reading sent is updated at step 744 and the green LED

flashed. If an error is detected during the transmission then the red LED is flashed to indicate a failure.

Referring to Figure 4, the server 400, which is set up to receive, maintain and analyse records for a number of patients. An interface in the form of an embedded GSM card 402 receives messages including data from a number of different interface devices, 106 (intended data) or any other source of SMS messages (such as unwanted 'spam'). This includes a queue 472 for received messages, a module 474 for decoding and validating the received SMS messages before they are input to the database, and a queue 476 for messages waiting to be sent from the server 400. The acquisition routine 470 manages the interface 402 to both send and receive SMS messages. Data from valid received messages are added to the database 410. The database 410 has a number of different tables. One of these tables 412 has stored in it, readings from each patient. Another 414 has patient details stored in it, including personal details, settings for the particular data device they are using, and alarm levels defining conditions in which an alarm needs to be raised for each patient. Another table 416 holds a patient summary for each patient, including summary data derived from the actual readings for the patient. A further table 418 contains an event table recording, for example, received messages, queries submitted and alarms raised for each patient. The processing system 420 is arranged to wait 430 until it is triggered by a processing event, which can be the presence of an unprocessed received message in the event table 418 or a scheduled time, and when triggered, to perform 432 certain calculations on the data for one or more patients. These can include calculating average values and variations of the measured parameter, which can be input to the patient details 414 or the patient summaries 416. The processing system is also arranged to check for alarm conditions defined for each patient, and, if required, to generate 434 alarm actions such as generating SMS messages or emails to be transmitted to the patient. Details of such alarms are recorded in the event table 418.

The server 400 is also arranged to run a reporting application 450 which makes information from the database available to the clinician via a web server as a set of web-pages 452. An HTML page request from a client computer (not shown) is processed by the web-server 451 to execute the appropriate server script which in turn produces the required HTML code for the requested page. Pages are included to configure the system, display results in tabular or graphical form and send feedback to the patient. Example pages are: a page 456 for preparation, of reports and graphical representations of results, so that these can be tailored to the specific requirements of any user of the system, a page 458 which allows for preparation and sending 460 of messages, such as SMS messages, and a page 462 which allows for configuration 464 of the system to suit different data devices and patients and provide different display and update options for the data. Each of these functions uses data from the database 410 which is accessed via a database query module 468.

In embodiments of the invention, the data processing system may include an alert system for alerting a user. The alert system may alert the user when, for example, one or more communications are received that indicate abnormal data. For example, one or more communications may be received that indicate an abnormal health of an individual, for example an abnormal glucose level. Additionally or alternatively, the alert system may alert the user when data has not been received indicating the health of an individual for a certain period of time (for example, a predetermined period of time). The alert system may alert the user, for example, by displaying a message or indication on a web page and/or sending a communication to the user. The user, once alerted, may be able to take appropriate action, such as reminding the individual to use the data device and/or arranging emergency treatment of the individual.

Embodiments of the invention may thus be used by an individual for monitoring their health using the data device, and for the data obtained on the health of the individual to be conveniently provided to a data processing system. This may

enable more effective monitoring of the health of the individual and may allow appropriate action to be taken, which may reduce the requirement of the individual to use a hospital bed and/or require health expenditure.

All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.

Each feature disclosed in this specification (including any accompanying claims, abstract and drawings), may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

The invention is not restricted to the details of any foregoing embodiments. The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed. The claims should not be construed to cover merely the foregoing embodiments, but also any embodiments which fall within the scope of the claims.