FI126007B

FI126007B - Glucose monitoring procedures and devices

Info

Publication number: FI126007B
Application number: FI20146063A
Authority: FI
Inventors: Tomasz Burda; Nicolas Mabragana; Antti Virkamäki; Kristian Ranta
Original assignee: Mendor Oy
Priority date: 2014-12-03
Filing date: 2014-12-03
Publication date: 2016-05-31
Also published as: WO2016087714A1; FI20146063A

Description

Methods and Apparatuses for Glucose Level Monitoring

FIELD OF THE INVENTION

The present invention relates to methods and apparatuses for monitoring of glucose level in a test subject or in a sample from a test subject.

BACKGROUND OF THE INVENTION

Glucose level is typically, but not exclusively, measured from blood, which is why the following description frequently refers to a “blood glucose meter”. A generic problem in prior art blood glucose level monitoring systems is that isolated blood glucose level measurements, that is, measurements without regard to events that significantly affect glucose level in blood, have very low informative value to health care professionals. US patent 8781752 discloses a method and arrangement for controlling a measurement process of blood glucose of a test subject (“patient”). Said '752 patent introduces pair measurements, wherein one measurement is taken before and the other one after events that have a significant influence on blood glucose level. A particular problem is that prior art blood glucose level monitoring systems either require continuous attention from users or their outputs have low informative value. Attempts to solve this problem have increased the complexity of the blood glucose monitoring device (meter) and/or its energy consumption.

SUMMARY OF THE INVENTION

It is an object of the present invention to alleviate one or more of the problems identified above. This object is attained with methods and apparatuses as defined in the attached independent claims. The dependent claims and the following detailed description, along with the attached drawings, relate to particular embodiments and implementation details that solve additional problems and/or provide additional benefits.

An aspect of the present invention is a method comprising: - an initial set-up phase; - multiple recurring monitoring phases; and - one or more reporting phases; the initial set-up phase comprising the following acts performed by a server for each of several clients: - setting up a client account for the client, wherein the act of setting up the client account for the client comprises storing an association that associ ates the client account with identification data of the client, client-specific communication information and an identifier of at least one glucose meter; - setting up a client-specific measurement schedule that defines a set of recurring events and times of the recurring events for the client; wherein at least one of the recurring monitoring phases comprises: - the at least one glucose meter using its identifier to upload to the server one or more glucose level measurements of the client with associated timestamps; - the server associating the one or more glucose level measurements and timestamps with the client account associated with the identifier of the at least one glucose meter; - the server comparing the timestamp of each uploaded glucose level measurement with a client-specific measurement schedule and arranging uploaded glucose level measurement as a pre-event measurement or postevent measurement, if the timestamp coincides with a pre-event time window or post-event time window respectively, for a glucose level-related event defined in the client-specific measurement schedule; - the server acknowledging the number of glucose level measurements uploaded in the recurring monitoring phase; - the server sending at least one indication of a reminder time to the at least one glucose meter; - the at least one glucose meter using the at least one sent indication of the reminder time to provide a measurement reminder at the reminder time; wherein at least one of the one or more reporting phases comprises: - the server receiving the client-specific login information and a request for a status report with respect to the client account associated with the client-specific login information; - the server responding to the request by sending a status report based on uploaded glucose level measurements and timestamps associated with the client account.

Other aspects of the present invention include apparatuses as defined in the independent claims other than claim 1.

In some embodiments the blood glucose meter obtains a correct time during at least some of the multiple recurring monitoring phases and synchronizes its internal clock with the obtained correct time. In some implementations the blood glucose meter obtains the correct time from the server. Alternatively or additionally, the blood glucose meter may obtain the correct time from an operator network via which the blood glucose meter communicates with the server.

In some embodiments the initial set-up phase comprises: - the blood glucose meter using its identifier to request a security token from the server; - the server responding to the request for the security token by sending a pseudo-random security token to the blood glucose meter; - the blood glucose meter indicating the pseudo-random security token on its user interface; - the server receiving the pseudo-random security token from a terminal used by the client, whereby the server authenticates the client.

In some embodiments the blood glucose meter has at least one network address, which the blood glucose meter uses to communicate with the server. In some implementations the at least one network address of the blood glucose meter is distinct from identifier of the blood glucose meter. The at least one network address of the blood glucose meter may comprise an internet protocol address and/or a cellular network address. For instance, a cellular network address may be obtained from a subscription identity module residing in the blood glucose meter. The subscription identity module may be an embedded subscription identity module, which may or may not be detachable.

The blood glucose meter may implement a flight mode, wherein all electromagnetic transmission is suspended.

In order to minimize energy consumption and to extend battery life, the blood glucose meter may further implement a power-saving mode wherein, for example, some or most of the circuitry is powered off and a watchdog circuit periodically powers up some of the meter to detect a condition, which may require waking up the meter to full operational status. Such a wake-up condition may include, for example, a user interface act, such as a long press of a predefined input element (eg a long press on an “activate” or “enter” button], or the insertion of a test strip. Alternatively or additionally, the wake-up condition may include triggering by a recurring event, which may occur at fixed intervals, such as once in each 24-hour period. In some implementations the wake-up triggers are linked to the client-specific measurement schedule, whereby the meter is automatically in a ready state when a scheduled event is approaching. The meter may optionally remind the user to take a measurement. In some implementations the meter may be programmed to connect with the server, either every time it wakes up or less frequently, such as once in each 24-hour period. When the meter connects with the server, it may upload measurement results to the server and/or check for the availability of downloadable content, such as updated measurement schedules, instructions for the user, software updates, and so on.

In some embodiments the blood glucose meter may implement a “guest” mode, wherein the blood glucose meter does not associate blood glucose measurements with the client. In some implementations the “guest” mode may be part of a service mode.

TERMINOLOGY

“Glucose meter” refers to an instrument configured to measure concentration of glucose in a sample of the test subjects blood or other fluid, such as tissue fluid. Glucose level is typically measured from blood, in which case the glucose meter may be referred to as “blood glucose meter”. “Client” means a person who, from the point of view of the data processing system, appears as the user of the glucose meter. A client registers and manages a client account. In a typical but non-restrictive case, the client is also the user of the glucose meter. Also, typically the client/user is also the test subject whose glucose level is being measured, but in some cases the test subject is unable to carry out measurements, as the case may be with minors, handicapped or elderly people, or animals. "Client terminal" refers to a communication terminal, which the client uses for communicating with a server. Although the glucose meter is technically a client of the server, a typical implementation of the present disclosure aims at improving client experience by carrying out interactive communication with the client via client terminals, which are distinct from and have more capable user interfaces than the glucose meters.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following section, specific embodiments of the invention will be described in greater detail in connection with illustrative but non-restrictive examples. A reference is made to the following drawings:

Figure 1 shows an exemplary data processing architecture suitable for implementing embodiments of the invention;

Figure 2 shows a schematic block diagram of a blood glucose meter, which can be used in embodiments of the invention;

Figure 3 illustrates the concepts of measurement schedule, measurement pairs and time windows; and

Figure 4 is a signaling diagram, which illustrates a hypothetical scenario in an embodiment of the invention.

DETAILED DESCRIPTION OF SOME SPECIFIC EMBODIMENTS

In the attached drawings, boxes shown with a dashed outline generally denote optional elements, which provide additional features and/or solve additional problems. Figure 1 shows an exemplary data processing architecture that can be programmed to perform the various data processing tasks relating to embodiments of the invention.

An element of the presently described embodiment is an information processing server, denoted by reference number 1-100. The server 1-100 comprises one or more central processing units CPI... CPn, generally denoted by reference numeral 1-110. Embodiments comprising multiple processing units 1-110 are preferably provided with a load balancing unit 1-115 that balances processing load among the multiple processing units 1-110. The multiple processing units 1-110 may be implemented as separate processor components or as physical processor cores or virtual processors within a single component case. In a typical implementation the server 1-100 comprises a network interface 1-120 for communicating with various data networks, which are generally denoted by reference sign DN. The data networks DN may include local-area networks, such as an Ethernet network, and/or wide-area networks, such as the internet. In the illustrative implementation shown in Figure 1, the server communicates with multiple client terminals CT, three of which are denoted by reference signs CT1, CT2 and CT3, over a data network DN. In the present implementation, client terminal CT1 is coupled to the data network DN via a wired router R, while client terminals CT2 and CT3 are coupled to the data network DN via a router/access point R/AP, which provides wireless access to the client terminals CT2 and CT3. The server 1-100 has a network interface 1-120 for communicating with client units over the data network DN.

The server 1-100 communicates with blood glucose meters over an access network, denoted by reference sign AN. In Figure 1, the data network DN and access network AN are shown as distinct networks, each of which has a dedicated interface in the server 1-100. As shown in Figure 1, the server 1-100 connects to the data network, such as the internet, over a network interface 1-120, and to the access network, such as a mobile cellular network, over a mobile network interface 1-125. The network interface 1-120 mobile network interface 1-125 are shown with dashed outlines because at least one of them can be omitted in simpler implementations wherein, for example, the access network AN uses a gateway interface (not shown) to couple to the data network DN, in which case a separate mobile network interface 1-125 is superfluous. Skilled readers will understand that a wide range of functionally equivalent implementations are possible.

The server 1-100 may optionally comprise a local user interface 1-140. Depending on implementation, the user interface 1-140 may comprise local input-output circuitry for a local user interface, such as a keyboard, mouse and display (not shown). Other implementations are also possible. For instance, the server 1-100 may be remotely managed, in which case a local user interface 1-140 is superfluous.

The server 1-100 also comprises circuitry for various clocks, interrupts and the like, and these are generally depicted by reference numeral 1-130.

The server 1-100 also comprises memory 1-150 for storing program instructions, operating parameters and variables. Reference numeral 1-160 denotes a program suite for the server computer 1-100.

The server 1-100 further comprises a storage interface 1-145 to a storage system 1-190. The storage system 1-190 comprises non-volatile storage, such as a magnetically, optically or magneto-optically rewritable disk and/or nonvolatile semiconductor memory, commonly referred to as Solid State Drive (SSD) or Flash memory. When the computer is switched off, the storage system 1-190 may store the software that implements the processing functions, and on power-up, the software is read into semiconductor memory 1-150. The storage system 1-190 also retains operating data and variables over power-off periods. The various elements 1-110 through 1-150 intercommunicate via a bus 1-105, which carries address signals, data signals and control signals, as is well known to those skilled in the art.

The inventive techniques may be implemented in the server 1-100 as follows. The program suite 1-160 comprises program routines or program code instructions for instructing the processor or set of processors 1-110 to execute the functions of the present disclosure. In addition, the program suite 1-160 may store instructions for carrying out normal system or operating system functions, such as resource allocation, inter-process communication, or the like.

Figure 2 shows a schematic block diagram of a (blood) glucose meter, denoted by reference sign GM, which can be used for data acquisition and processing tasks in embodiments of the invention. The glucose meter GM comprises a processing system 2-02 with at least one central processing unit. The glucose meter further comprises a memory system 2-50, which typically comprises a combination of fast volatile memory and slower non-volatile memory, as is well known to those skilled in the art. In addition, the glucose meter GM comprises or utilizes a user interface 2-10, which comprises an input circuitry 2-12 and an output circuitry 2-14. The input circuitry 2-12 comprises the glucose meter’s keypad and/or a touch input function of a touch screen, if the meter has one. Alternatively or additionally, the input circuitry may comprise a voice input subsystem. The output circuitry 2-14 comprises the blood glucose meter's display and/or output function of a possible touch screen. The output circuitry 2-14 preferably comprises an audio output subsystem and/or one or more alerting devices, with which the glucose meter GM is able to remind the client (user) of scheduled measurements. The one or more alerting devices typically at least one blinking light and/or electromechanical devices that oscillate at audible frequencies, thereby producing audible sounds, or frequencies lower than audible frequencies, thereby producing tactile vibrations. Any combinations of the above alerting devices are possible to generate a broad range of alert signals. Examples of oscillating electromechanical alert devices include loudspeakers, piezoelectric devices, such as buzzers, motors with unbalanced loads, or the like. Instead of local alerting devices, which generate reminders in the vicinity of the glucose meter, or in addition to such local reminders, it is possible to send electronic messages, such as text messages or e-mails to one or more external devices, such as the client terminal registered with the client account.

In some embodiments the glucose meter GM further comprises a cellular network interface 2-20, which comprises a transmission circuitry 2-22, reception circuitry 2-24 and antenna 2-26. A subscriber identity module, SIM, 2-30 is used by an authentication function to authenticate the blood glucose meter’s user and to identify the user’s subscription to the access network AN. In some embodiments, the glucose meter also comprises WLAN (Wireless Local Area Network) circuitry 2-34, via which the glucose meter is capable of acting as a WLAN client to a WLAN base station (shown as a router/access point R/AP). In some implementations, the SIM module is a Machine-to-Machine, or M2M, SIM. An M2M SIM may be implemented as an embedded SIM, in which case the glucose meter GM

does not need a physical slot or opening for a detachable SIM card. A benefit of the cellular network interface is that blood glucose meter can connect with the server virtually everywhere and without attachment cables and without user interaction that is typically needed with WLAN or Bluetooth interfaces.

Reference number 2-36 denotes an optional wired connector, which can be used for additional functions in some embodiments. For instance, the wired connector 2-36 may be a USB connector, which can be used for charging the battery of the glucose meter and/or for connecting with an external data processing device, such as a client terminal CT. The client terminal CT or another data processing device may be used for upgrading the software of the glucose meter, customizing its operating parameters, such as measurement schedules, uploading measurement data from the glucose meter, and/or resetting the glucose meter to initial factory settings.

In addition to the user interface 2-10, the blood glucose meter typically comprises a set of internal sensors 2-40 for measuring the glucose level from an extracted blood sample. As regards measuring the glucose level from the blood sample, the glucose meter GM can be implemented by using techniques known in the art. In a typical but non-restrictive implementation, the glucose meter has a connector for receiving a disposable test strip, which contains the chemical system for an enzymatic process which changes a measurable property by an amount that depends on glucose level of the blood sample. The dashed outline 2-42 indicates that the input connector 2-40 for the enzymatic test strip can physically reside within or outside the enclosure of the glucose meter. In a dedicated glucose meter it is generally preferable to place the input connector 2-40 for the test strip within the enclosure, in order to attain a robust and compact design. On the other hand, by producing a detachable connector for the test strip, it is possible to use an existing, non-dedicated, data processing device, such as a smartphone, to provide a user interface, communication interface(s) and processing functions for a glucose meter. Those skilled in the art will understand that other types of chemical systems can be used. Key here is that the glucose meter obtains a signal that is indicative of the glucose level in a blood sample from the test subject. Other embodiments may employ other means to obtain glucose measurements, such as subcutaneous continuous measurement, optical measurement of glucose through the skin, or any other quantitative techniques of measuring glucose levels in a body fluid, such as blood.

Reference number 2-50 denotes a memory system. The memory system stores program code instructions 2-60 for instructing the processing system 2-02 to execute the functions of the glucose meter. In a typical implementation the memory system also stores parameters, such as an identifier or serial number of the glucose meter, and operating variables, in which the data processor stores short-term data needed in further processing phases.

Figure 3 illustrates the concepts of measurement schedule, measurement pairs and time windows. These concepts relate to various optional features of the present disclosure. As is well known, blood glucose level varies over time, depending on events which increase or decrease glucose level in blood. Examples of such events are meals, exercises, sleep and insulin intake. Therefore a single glucose level measurement conveys very little useful information to a health care professional. Measurements, which can be related to the events which affect glucose level, are much more useful than isolated measurements. Figure 3 relates to a use case, wherein a number of events occur with sufficient regularity to be useful in measurements. Reference signs RE1 ... RE3 denote recurring events. In the present example, recurring event RE1 is overnight sleep, while recurring events RE2 and RE3 are regular meals. Reference number 3-100 denotes a 24-hour period on a date/time scale. Reference sign RE1’ denotes a copy of recurring event RE1 for a following 24-hour period. Event RET is shown merely to illustrate the periodicity of the recurring events and need not be defined or stored separately because it follows the definition for event RE1.

In an illustrative implementation, each recurring event has a respective definition for start and end time (or start time and duration, from which the end time can be derived). Each of the start and end time has a respective time window. For instance, time windows WnA and WnB are the time windows for the start and end, respectively, of event REn, wherein n=l, 2, or 3. In the presently described diagram, which is purely illustrative, the overnight sleep RE1 has start and end time definitions of 22:00 and 06:00, respectively. Time windows W1A and W1B with widths of two hours are shown as centered around the start and end times. At least one regular measurement should be taken during each of the predefined time windows.

Reference sign RE2 denotes a first meal, for which a pair of time windows W2A and W2B have been defined. By way of example, a profile set-up routine (cf. item 4-120 in Figure 4) may determine that the test subject typically has the first meal between 11:30 and 13:30, and sets up the first time window W2A

from 11:00 to 12:30 and the second time window W2B from 13:00 to 14:30. The start and end times and durations described here are purely illustrative and do not restrict the present disclosure. Similar time windows W3A and W3B are set up for the second meal RE3.

In other implementations, the second measurement window W2B can be set based on the actual time of the first measurement. By way of example, if a measurement falls within a first window, the second window can be set to occur a certain time after that first measurement, (for example 2 hours +/-30 minutes).

The identification of the first measurement falling within the first window W2A, and the setting of the W2B window can be performed a) by the server after receiving the first measurement and then sending reminders related to the W2B window to the meter, b) by the meter automatically, c) by the user tagging the measurement as a pre-event measurement manually.

In the case of several measurements occurring within a window, it is possible to select one of the measurements, a statistically representative value of the several measurements, such as an average, or another computation of the values and measurement times. As a further alternative, the user may be able to mark the correct / incorrect measurements via the user interface of the glucose meter and/or via a connection to the server from a client terminal, by using a browser or a dedicated software program.

Reference signs MnA, MnB, wherein n=l, 2 or 3, denote measurements that are supposedly and preferably taken within the respective time windows WnA and WnB. In the scenario shown in Figure 3, measurements MIA, M1B, M2A, M2B and M3A occur within their respective time windows W1A, W1B, W2A, W2B and W3A, but measurement M3B occurs outside of its time window W3B. In some implementations, measurements that occur outside of their respective time windows, such as exemplary measurement M3B, are treated differently from measurements that occur within their respective time windows. For instance, the out-of-window measurements can be classified as having low informative value, discarded altogether, or heavily weighted down in analyses, or they may be analyzed differently.

Managing the measurement schedule, time windows and reminder times related to the client account primarily in the server has the benefit that such management functions reduce the complexity and energy consumption of the blood glucose meter compared with techniques wherein the blood glucose meter is entirely responsible for such management functions. A server-based im plementation also allows for various channels of data output to devices with established user interfaces, such as a web browser, mobile applications, or the like.

Figure 4 is a signaling diagram, which illustrates a hypothetical scenario in an embodiment of the invention. The nodes discussed herein have been described in connection with Figures 1 and 2 (client terminal CT1 - CT3, glucose meter GM1, GM2, operator networks DN, AN and server 1-100) and a repeated description is omitted.

Reference number 4-100 denotes an initial set-up phase, which in a typical implementation comprises two sub-phases. Reference number 4-110 denotes a phase for setting up a client account on the server from a client terminal. Setting up the client account comprises storing an association that associates the client account with the client, an identifier of a specific glucose meter and communication information of the client. Typically the identifier of the glucose meter is the meter’s serial number, but other identifiers may be used. What is important is that the meter itself can read its identifier from a data source, such as ROM memory. By way of example, the communication information of the client may comprise login information, by which the client can log in to the server. The login information may comprise a client identifier/password combination or any other suitable information for logging in to a server. Alternatively or additionally, the communication information of the client may comprise an e-mail address of the client, which the server can use to initiate communication with the client terminal.

In an optional sub-phase 4-120, which may take place in the same session with or in a different session from sub-phase 4-110, the client terminal receives prompts from the server and client’s instructions from its user interface and cooperates with the server to set up a client profile. The client profile is associated with the client account that was set up in sub-phase 4-110. For the purposes of the present disclosure, the client profile also comprises a schedule for recurring events with respective time windows, as was described in connection with Figure 3. The client account and client profile may, and typically do, contain other information elements, such as the test subject’s name, address, birth year, sex and so on, but such information elements are relatively unimportant for the present disclosure. The client account may also store name and address information for the client in cases where the client is different from the test subject associated with the glucose meter.

Reference number 4-200 denotes one of several recurring monitoring phases. Reference number 4-210 denotes an act or step wherein the glucose meter carries out a glucose level measurement. The glucose meter timestamps the measured glucose level measurement (associates the measurement with the meter’s current time) and stores the measurement result in medium-term memory for subsequent uploading to the server. The measurement step 4-210 can be executed several times before the next uploading.

In step 4-220 the glucose meter uploads pending glucose level measurements, that is, measurements that have not yet been uploaded to the server. Each measurement is accompanied with its respective timestamp. The glucose meter also sends its identifier that was associated with the client account in the set-up phase 4-110. In step 4-222 the server stores the uploaded measurement(s) and its/their respective timestamp(s). In particular, the server retrieves the client account that corresponds to the glucose meter’s identifier, such as serial number, and couples the measurement(s) and timestamp(s) with the retrieved client account.

Optional step 4-224 relates to embodiments, which implement the time windows described in connection with Figure 3. In step 4-224, the server compares the timestamp(s) of the currently uploaded measurement(s) with the time windows, which it retrieves from the client profile that was set up in subphase 4-120. If the timestamp(s) correspond to time window(s) of the client profile, the measurement(s) is/are classified as pre-event measurement(s) or postevent measurement(s), as was described in connection with Figure 3 (MnA, MnB are pre-event and post-event measurements, respectively).

In order to account for cases where the glucose meter’s internal clock is off, or in a time zone not known to the server, the glucose meter may send its own current time along with the measurements and timestamps. The server can then compare the current time sent by the glucose meter, detect a possible discrepancy and adjust the timestamps to a known and correct reference time, such as UTC.

In step 4-230 the server acknowledges the successfully uploaded measurements to the glucose meter. In step 4-232, as a result of the acknowledgment, the glucose meter marks the measurements as uploaded, and these will not be uploaded again. The glucose meter can then reclaim the memory space used by uploaded and acknowledged measurements.

In an optional step 4-234 the server sends status and/or instruction messages, which the server may select or create automatically based on current measurement history. Such messages may comprise purely informative status messages, such as “40% of lunch pairs completed”. Alternatively or additionally, the messages may comprise encouraging statements, such as “Good job”, or “The timing of your measurement is improving”. Yet further, the server may send messages that instruct the user to contact a health care professional. In step 4-236 the meter outputs the message(s) sent in step 4-234 via its display and/or audio output.

In step 4-240 the glucose meter uses the current connection with the server to obtain a correct time. Figure 4 shows an implementation wherein the glucose meter obtains the correct time from its local operator's network. Alternatively or additionally, the glucose meter may obtain the correct time from the server. Obtaining the correct time from the local operator’s network has the benefit that the time is automatically current local time. In contrast, the server may not know where the glucose meter is located, and without such information it may not be able to determine which time is current local time for the client or test subject and which time windows have expired and which have not.

In step 4-250, let us assume that the server detects that all of the following conditions are simultaneously true: - the measurement results and timestamps uploaded in step 4-220 include a measurement that occurs within one of the pre-event windows (WnA in Figure 3); - the post-event window for the measurement identified in the previous step (WnB in Figure 3) has not expired; and - the uploaded measurement results and timestamps do not include a measurement that occurs in the post-event window identified in the previous step.

Or, to put it simply, a pre-event window contains a measurement but the corresponding post-event window does not, and has not expired. If these conditions are true, the server sends an indication of a reminder time to the glucose meter. The reminder time is either the current time or the beginning of the postevent window, whichever is later. In other words, if the post-event window has already begun but has not expired, the reminder time is the current time. On the other hand, if the post-event window has not begun, the reminder time is the beginning of the post-event window.

In addition to such individually determined reminder times, the server may send the glucose meter a semi-permanent reminder schedule, which is derived from the time windows of the client profile, as was described in connection with Figure 3. For instance, the reminder schedule may comprise reminders at the beginning of each time window. Alternatively or additionally, the reminder schedule may comprise reminders closer to the end of each time window, in which case the glucose meter does not have to provide reminders for measurements that the client or user has already performed.

This concludes the description for a recurring monitoring phase 4-200 in an embodiment of the present disclosure. Skilled readers will understand that some steps, such as measurement steps, can be repeated several times in one recurring monitoring phase, and some steps can be omitted in simpler embodiments. For instance, arranging measurements into pairs and detection of the related time windows, as well as providing reminders or alerts to the user, may optionally be performed in the glucose meter, differently to the previous description wherein these acts are performed in the server. The server-based implementation has the benefit, however, that the glucose meter can be simpler and its battery is likely to last longer, assuming otherwise equal conditions.

In step 4-290 the glucose meter detects that the current time coincides with one of the reminder times the meter downloaded from the server, or with a post-event measurement window whose timing is based on the timing of the corresponding pre-event measurement made by the glucose meter. As a result, the glucose meter provides a reminder to the client or user. The reminder can cause an audible, visible and/or tactile stimulus to the client or user, as was described in connection with Figure 2. Alternatively or additionally, the glucose meter can send a reminder as a message to a mobile device of the user or client.

In step 4-300 the glucose meter performs another glucose level measurement. This step begins the next occurrence of a recurring monitoring phase 4-200. The recurring monitoring phases can be repeated for several days, which need not necessarily be consecutive days. The recurring monitoring phases can include measurements over a 1st meal, 2nd meal, and/or regular sleep, for example,

Reference number 4-400 denotes an interactive reporting phase between the client terminal and the server. In one implementation, the client terminal receives or stores the client’s login information and logs on the client account on the server. The server retrieves measurement results and timestamps associ ated with the client account and sends analysis-related information, such as a line graph of measurement history, trend information, or the like, to the client terminal.

Those skilled in the art will realize that the inventive principle may be modified in various ways without departing from the scope of the present invention. For instance, it is possible to present data related to several client accounts at the same time. For example, a health care professional may be able to see the status of all of their patients, including the number of measurements and measurement pairs, statistically representative changes during events, average glucose values, hypoglycemia indicators, or the like. It is also possible to prioritize treatment and detect if a patient is not measuring due to low compliance or a possible incident. The meter and other communication can be localized to several languages. Measurement units (such as mmol/L, mg/dL) can be fixed or user-selectable, possibly during a setup phase.

Claims

A method comprising: - an initial setting step (4-100); multiple repetitive monitoring steps (4-200); and - one or more reporting steps (4-400); wherein the initial setup step comprises the following steps (1-100) performed by the server for each of the plurality of clients: - establishing (4-110) a client account for the client, wherein establishing the client account for the client comprises: storing an association associating the client account with the client identity data, client specific communication information; the tag; generating a client-specific measurement schedule that defines a set of recurring events and times of recurring events for the client; wherein at least one of the repetitive monitoring steps (4-200) comprises: - at least one glucose meter using its identifier to upload (4-220) to the server one or more glucose levels measurements by the associated time stamps; the server associates one or more glucose level measurements and a time stamp with the identifier of the at least one glucose meter in an associated case box; - the server compares (4-222) the time stamp of each loaded glucose level measurement with a client-specific measurement schedule and arranges the loaded glucose level measurement for pre-event measurement (MIA, M2A, ...) or event-subsequent measurement (M1B, M2B, ...) if timestamp is concurrent with the pre-event time window (W1A, W2A, ...) or post-event time window (W1B, W2B, ...) of the glucose level event (RE1, RE2, ...), respectively, wherein the pre-event time window is defined from a client-specific measurement schedule; the time window following the event is determined from a client-specific measurement schedule or a time stamp of the corresponding pre-event measurement; the server acknowledges (4-230) the number of glucose level measurements downloaded during the repeated monitoring step; the server transmitting (4-250) at least one indication of a reminder time to the at least one glucose meter; - the at least one glucose meter uses at least one transmitted indication of a reminder time to produce a measurement reminder (4-290) during the reminder time; wherein at least one of the one or more reporting steps comprises: - receiving, by the server, client-specific login information and a request for a status report relating to the client-specific login information associated with the client-specific login information; the server responds to the request by sending a status report based on the downloaded glucose level measurements and time stamps associated with the client account.

The method of any one of the preceding claims, wherein the at least one glucose meter receives the correct time (4-240) during at least some of the repeated monitoring steps and synchronizes its internal clock with the obtained time.

The method of claim 2, wherein the at least one glucose meter receives the correct time from the server.

The method of claim 2, wherein the at least one glucose meter receives the correct time from the operator network through which the glucose meter communicates with the server.

The method of any preceding claim, wherein the initial setup step comprises: - at least one glucose meter using its identifier to request a security token from the server; - the server responds to the security token request by sending a I-P random security token to at least one glucose meter; - at least one glucose meter displays a pseudorandom security token in its interface; the server receives a pseudorandom security token and then authenticates the client.

The method of any one of the preceding claims, wherein the at least one glucose meter has at least one network address used by the at least one glucose meter to communicate with the server.

The method of claim 6, wherein the at least one network address of the at least one glucose meter is separate from the identifier of the at least one glucose meter.

The method of claim 6, wherein the at least one glucose meter is at least one blood glucose meter.

A server computer (1-100), comprising: - a memory system for storing program code commands and data; a processing system having at least one processing unit, the processing system executing at least a portion of the program code instructions and processing the data; a plurality of network interfaces for connecting a server computer to each of the plurality of glucose meters and each of the plurality of client computers through one or more telecommunication networks; wherein the memory system stores program code commands that, when executed by the processing system, cause it to perform the following steps: initializing step (4-100): - establishing (4-110) a client account for the client, wherein establishing the client account for the client comprising: storing an association associating the client customer-specific login information and the identifier of at least one glucose meter; generating a client-specific measurement schedule that defines a set of recurring events and times of recurring events for the client; at least one of the repetitive monitoring steps (4-200): receiving, from the at least one glucose meter, an identifier and customer-loaded (4-220) glucose level measurements with associated time stamps; associating one or more glucose level measurements and timestamps to one or more glucose meter identifiers in an associated client account; - comparing (4-222) the time stamp of each downloaded glucose level measurement with a client-specific measurement schedule and arranging the loaded glucose level measurement as a pre-event measurement (MIA, M2A, ...) or a post-event measurement (M1B, M2B, ...), respectively. a glucose-level event (RE1, RE2, ...) with a pre-event time window (W1A, W2A, ...) or a post-event time window (W1B, W2B, ...), where the pre-event time window is defined from a client-specific measurement schedule and event. the next time window is determined from the customer-specific measurement schedule corresponding to the pre-event measurement timestamp; - acknowledging (4-230) the number of glucose level measurements downloaded during the repeated monitoring step; - sending (4-250) at least one indication of a reminder time to at least one glucose meter; at least one reporting step of: - receiving client-specific login information and requesting a status report for a client account associated with the client-specific login information; - responding to the request by sending a status report based on downloaded glucose level measurements and timestamps associated with the client account.

The server computer of claim 9, wherein the one or more telecommunication networks comprises at least one wireless network.

A server computer according to claim 9 or 10, wherein the plurality of network interfaces comprises interfaces for a plurality of different telecommunications networks.

The server computer of claim 9, 10 or 11, wherein the program code commands executed by the processing system cause it to perform the following actions: - receiving a security token request for at least one glucose meter identifier; - responding to a security token request by sending a pseudorandom security token to at least one glucose meter; receiving a pseudo-random security token from the client terminal used by the client; - authenticating the client whose client terminal sent a pseudo-random security token.

13. Hardware comprising: - a memory system for storing program code commands and data; a processing system having at least one processing unit, the processing system executing at least a portion of the program code instructions and processing the data; - user interface; - glucose level measuring circuit; - the available identifier of the processing system; a plurality of network interfaces for connecting the hardware to at least one server via one or more telecommunication networks; wherein the memory system stores program code commands that, when executed by the processing system, cause it to do the following: before each one or more repetitive monitoring steps (4-200}: - performing one or more measurements of the subject's glucose (4-210}; using an identifier to load (4-220} the server one or more test subject glucose level measurements with associated timestamps; - receiving an acknowledgment from the server (4-230} for the number of glucose level measurements downloaded; time indication over the network that connects the hardware to the server - use the correct time indication to synchronize the internal clock of the hardware before the next repetitive monitoring step (4-200}: - use at least one transmitted indication of reminder time to generate measurement memory utus (4-290} during the reminder period.