Patent Description:
In a health monitoring environment, such as a hospital or a nursing home, a monitoring of vital sign data from the patients may be performed by means of a vital sign sensor attached to each patient. Furthermore, there may be one or more receiving computing devices distributed within the hospital in such a way that they cover the whole building, enabling a BLE communication between the receivers and the sensors. When using a BLE communication in connection mode to send the data obtained by the sensors to one or more receivers, there is a limitation in the number of sensors that can be connected simultaneously to each receiver, requiring at least one receiver per <NUM> sensors.

However, it is also known to send data captured from a sending device (such as sensor devices) to a computing device within a BLE advertising type frame, wherein there is no limitation of number of sensors per receiving computing device.

When using a BLE communication, either sending data in connection mode or within advertising type frames, important parts of data obtained and sent by a sensor may not always reach a receiving computing device. For example, when monitoring the health of a patient at home during a home hospitalization, a receiver may be located in a central part of the house, and it may receive data from a sensor attached to the patient, wherein the sensor may not always be within reach of the receiver. For example, when the patient walks far away from that part of the house (the patient goes for a walk), the signal from the sensor may be lost by the receiver.

Furthermore, a patient may be in a place but move its resting position (for example, when sleeping), obstructing the correct sending of the data from the sensor to a receiver. Such loss of data may happen in an unpredictable way (depending on, for example, if a patient hospitalized at home moves far away from the room where the receiver is located) or in a periodical and predictable way (for example, when the patients sleep, the sensor may usually have more obstructions to correctly send the sensor data to the receiver).

Therefore, a system for monitoring a vital sign of a patient may be needed, which guarantees a low loss of data, thus ensuring a continuous and correct monitoring of vital signs of a patient.

Prior art document <CIT> discloses a solution with switching from advertising to connection mode for sending patient sensor data. However, the criteria to switch is only about the content of the monitored data reaching critical values.

According to a first aspect, a method of remote monitoring of a vital sign of a patient is provided. More precisely, the method is performed by a computing device comprising a BLE communication module to communicate with a vital sign sensor, the method comprising the steps of:.

The method of remote monitoring is performed by a computing device which can be a smartphone, a tablet, a computer, or any similar device that comprises a BLE communication module, thus being able to communicate with other devices using a BLE protocol. Furthermore, the computing device is able to connect to a vital sign sensor using said BLE communication module, embedding data using a BLE protocol. More precisely, the vital sign sensor may be a sensor for capturing data related to, for example, body temperature, blood pressure, respiration and heart rates, oxygen saturation, electrocardiogram, blood glucose concentration, or brain waves from a patient.

According to the above method, the computer device receives a first BLE advertising communication packet from the vital sign sensor.

Bluetooth Low Energy (otherwise known as BLE) is a subset of the Bluetooth standard. It has a unique protocol stack in reference to the OSI layer and is oriented to simple connections in very low power applications useful for (battery-dependent devices).

As a communications protocol, BLE has very low power requirements (consumes <NUM>% to <NUM>% less energy than standard Bluetooth), has a much lower cost and an acceptable range in communications. Because of this, many smart home, health, automotive and even security devices use this type of communication protocol between the devices and the applications which control them.

Furthermore, any BLE protocol comprises at least two modes of communication: advertising mode and connected mode. Advertising mode communications are defined by the Generic Access Profile (GAP), wherein such communications are used to transmit data to any device who may be listening. On the other hand, connected mode communications are defined by the Generic Attribute (GATT), wherein such communications are used to transfer data through an already established Bluetooth connection between two devices.

Therefore, advertising mode may be defined as a one-to-many type of communication (i.e., a broadcast type of communication), while connected mode may be defined as a communication between two devices (i.e., a master - slave type of communication).

Advertising mode uses BLE advertising communication data packets to embed data, which may be defined by different types of advertising protocols within BLE advertising mode. The BLE advertising protocols define frames which comprise, generally, a header comprising data about the version of the protocol, length of the frame and command identifiers, and a payload section comprising useful information of the protocol.

The main existing BLE advertising protocols are, among others:.

Both iBeacon and Eddystone (or other types of BLE advertising protocols) embed data in a frame, wherein the frame comprises, as previously mentioned above, a plurality of fields to control and manage the communications between devices (within the header section), and a plurality of optional fields (within the payload section), which can be used by the device to send specific information about the state of the sending device, such as telemetry data related to the strength of the signal.

On the other hand, in connected mode, GATT (Generic Attribute Profile) defines how two BLE devices can communicate using the Services and Features. Once a dedicated connection has been established between two devices, the communication in connected mode is defined by GATT. In order to establish such communication in connected mode, a communication through the advertising mode (defined by GAP) has previously been carried out.

The most important characteristic of communications in connected mode is that they are exclusive. A BLE peripheral (such as a vital sign sensor) can only be connected to one central device (a computing device such as, for example, a smartphone) at a time. As soon as a peripheral is connected to a central device, it will stop advertising itself and other devices will no longer be able to see it or connect to it, until the existing connection is terminated.

When using BLE, establishing a communication in connection mode enables bidirectional communication, wherein the computing device can send data to the peripheral (for example, a vital sign sensor), and the peripheral can respond (and vice versa).

According to the method of the present disclosure, the received BLE advertising communication packet comprises a vital sign data packet. Such packet comprises data corresponding to at least one measurement obtained by the vital sign sensor. For example, the vital sign data packet may comprise data corresponding to a plurality of body temperature measurements performed by a body temperature sensor. Furthermore, for each portion of data corresponding to a sensor measurement, a timestamp is further generated. Said timestamp may be generated locally within the computing device (upon the arrival of the BLE advertising communication packet) or it may be obtained from the BLE advertising communication packet itself (for example, the timestamp may have been generated within the sensor, and embedded within the packet before being sent to the computing device). This way, the computing device receives data corresponding to the value of at least one measurement performed by the sensor, and when that measurement was performed (i.e., the generated timestamp, whether generated at the computing device or obtained from the received BLE advertising communication packet). Furthermore, the vital sign data packet may be embedded within one or more of the previously described optional fields of the BLE advertising frame. This way, by complying with the BLE protocol, the inclusion of a vital sign data packet does not affect the management and control of communications between the vital sign sensor and the computing device.

Afterwards, a verification is performed to determine if the difference between the generated timestamp and a stored timestamp of a previously received BLE advertising communication packet is higher than a predetermined waiting time. Thus, said verification is performed to assess if more than a certain time has passed between the reception of two BLE advertising communication packets.

Furthermore, for example, the previously described verification related to the difference between the generated timestamp and a stored timestamp would be useful if the user wearing the sensor has moved out of reach of the computing device. More precisely, if the computing device is a smartphone, the user may have left the smartphone in a room and may have walked out of the building. In this case, the computing device may have not received vital sign data embedded within one or more BLE advertising communication packets sent by the sensor while the computing device was out of reach of the sensor, thus losing said vital sign data, generated while being out of reach.

Subsequently, in case of positive result of the verification (i.e., a certain waiting time between the reception of two packets has passed), a BLE packet is sent from the computing device to the vital sign sensor, to establish a BLE communication in connected mode between the vital sign sensor and the computing device. Such BLE packet may be a request using any BLE protocol to establish a master-slave type of communication (i.e., a connected mode type of communication) between the computing device and the vital sign sensor. However, a specific set of instructions may be defined within the BLE protocol in order to perform the retrieval of vital sign data packets from the sensor, and, optionally, any timestamp corresponding to such packets.

Afterwards, through the established BLE communication in connected mode, a plurality of vital sign data packets are retrieved from the vital sign sensor (for example, from a memory connected to the sensor) and sent to the computing device. Such packets may be stored within a memory connected to the sensor and may correspond to timestamps with values between the received timestamp and the stored timestamp.

The predetermined waiting time may be determined by, for example, the specific application of the system. That is: if the aim of using the computing device and the sensor is to monitor the body temperature of a patient, the waiting time may be higher, since body temperature variations are slower than variations of other vital signs. Similarly, the monitoring of a patient's body temperature may be more critical when the patient has fever (more than <NUM>), thus choosing a shorter waiting time during fever episodes. Another example may be when the aim is to monitor blood pressure or heart rate of a user, wherein the monitoring is more reliable when the user is resting, and specially when he/she is sleeping. Therefore, in summary, the waiting time may be adjusted depending on the state of the patient, the type of monitoring being performed, or the time schedule of, for example, a doctor in charge of the monitoring.

In many cases, BLE advertising communication packets are used to initiate a communication in between two devices, which once initiated, is switched to a dedicated communication in between them in connected mode. Furthermore, such BLE advertising communication packets are also used to transmit telemetry data within the optional fields of its frame, which is useful for monitoring the performance of beacons or devices (i.e., elements of the devices which send such packets). Such telemetry is used, for example, by other receiving devices (any device reached by the BLE advertising packet) to assess if it is possible to establish a further BLE communication in connected mode.

However, the method of the present disclosure uses the optional data fields (which can comprise, for example, telemetry data) of BLE advertising frames to send a vital sign data packet, thus being able to send data related to vital sign measurements (such as body temperature, blood pressure, etc.. ) obtained from a vital sign sensor connected to the computing device.

Therefore, a BLE advertising communication packet (i.e., a packet sent using a BLE advertising mode protocol) is used to transmit vital sign data, instead of sending such vital sign data packets using a BLE connection mode type of communication (using BLE or other standard Bluetooth connection protocols in connected mode). This way, generally, by using such advertising packets instead of a connection mode type of communication, a substantial saving of energy is achieved within the vital sign sensor (that is, a saving of energy of the batteries of the vital sign sensor).

Furthermore, by controlling the periods when the computing device may periodically be within reach of the sensor, using a verification and a subsequent obtaining of vital sign data packets sent by the sensor while it was out of reach of the computing device, the frequency of the broadcasting (i.e., sending) of BLE advertisings packets may be adjusted for extra energy saving. For example, in a case when a patient wearing a sensor of the system uses the bathroom on a regular basis, or is out of reach of the computing device at predictable times during the day (for example, at lunch time, or during the night, while sleeping, when the sensor cannot reach the computing device properly), an extra saving can be achieved by avoiding the sending of BLE advertising mode packets during such periods of time, and waiting for the period of time for the computing device to most likely be reachable by the sensor.

Thus, according to another example, the method of remote monitoring of a vital sign of a patient further comprises a step of determining a pattern of availability of the sensor, based on at least one difference between a generated timestamp and a stored timestamp.

Because of this, the autonomy of the vital sign sensor (i.e., the autonomy of the battery of the vital sign sensor) can be substantially increased by adjusting the sending of the BLE advertising packets by the sensor, based on previous (single or multiple) iterations of the method, wherein it is possible to identify the patterns of availability of the sensor.

In addition to this, the vital sign data may not be lost while the sensor is out of reach of the computing device, and a single connection mode type of communication between the sensor and the computing device may be used in between periods where both devices are within reach and out of reach, to retrieve any lost data.

This is particularly useful when, for example, a substantially long period of time has passed between the BLE advertising communication packet last received by the computing device (for example, a packet that was stored by the computing device when received) and a new arriving BLE advertising communication packet.

Furthermore, a longer working distance may be achieved at a low computational cost. More precisely, there are receivers (for example, smartphones) that restrict the minimum power needed to maintain a BLE communication on a connected mode with a sensor (thus affecting the distance at which a connected mode type of communication can be established and/or maintained). This restriction is performed in order to avoid saturating the use of the antenna of the computing device (for example, a smartphone). This is because when both a sensor and a computing device are found nearby, within a limit distance between them (a zone wherein signal is weak) and the power of the BLE communication receiving signal is subsequently reduced, the receiving device uses a substantial amount of energy to ensure a stable connection (for example, by performing scans of the sensor, or restarting the connection between them). Therefore, some computing devices prevent the saturation of the antenna by limiting the required energy of the received signal to a minimum, to establish a communication in connected mode. Furthermore, there is no limitation of number of sensors per receiving device. When using a BLE communication in connection mode to send the data obtained by the sensors to one or more receivers, there is a limitation in the number of sensors that can be connected simultaneously to each receiver, requiring at least one receiver per <NUM> sensors. Therefore, by using BLE advertising mode type of communications, such limitations may be avoided.

According to an example of the present disclosure, the vital sign data packet may comprise data corresponding to at least one body temperature measurement performed by the vital sign sensor, and the method may further comprise a step of:.

and wherein, in case of positive result of the temperature verification, the value of predetermined waiting time is lowered.

According to an example of the present disclosure, the method of remote monitoring of a vital sign of a patient may further comprise the step of:.

and wherein the step of retrieving a plurality of vital sign data packets from the sensor is performed only in case of positive result of the first power verification.

More specifically, the power or RSSI (Received Signal Strength Indicator) of the received signal comprising the first BLE advertising packet may be measured, and compared to a predetermined power threshold. Said threshold may be a predetermined minimum power in order to establish a connected mode communication between the sensor and the computing device, which is most likely to be maintained while the subsequent retrieval of the packets is performed. Such situation may be important when a sensor is within the limit of the range of its advertising signal with the computing device (i.e., the computing device is almost out of reach of the sensor, so a connected mode type of communication may easily be interrupted if the sensor or the computing device move slightly further away from each other). Once a connected mode communication is established, and a positive result is obtained from said first power verification, the retrieval is performed. However, if a negative result is obtained from said first power verification, it would mean that, if the connected mode communication was established, it was likely to be interrupted while the retrieval was being performed. This would result in, for example, having to start the retrieval from the beginning, thus losing time and energy by doing so.

The predetermined minimum power limitation previously described may be established by each Operative System, by means of, for example, specific libraries or its preprogramed functions. Furthermore, an additional limitation may be established when performing the method according to the present disclosure, in order to further save battery while establishing a connected mode type of communication.

According to another example, the method of remote monitoring of a vital sign of a patient may further comprise the steps of:.

and wherein the step of retrieving a plurality of vital sign data packets from the sensor is performed only in case of positive result of the first power verification and the second power verification.

More specifically, to ensure that the retrieval of vital sign data packets using a connected mode communication will be less likely to be interrupted, a second power verification may also be performed (besides the first one corresponding to the first received BLE packet) on the signal comprising the second BLE advertising packet. This way, it may be verified that at least two received signals comprising BLE advertising packets are strong enough to further perform the subsequent retrieval (i.e., the signal coming from the sensor is strong enough to maintain a connected mode communication between the sensor and the computing device after being established).

According to another example, the method of remote monitoring of a vital sign of a patient further comprises the step of:.

and wherein the step of retrieving a plurality of vital sign data packets from the sensor is performed only in case of positive result of the first and second power verification and the second time verification.

Therefore, a further time verification may be performed, in order to determine if the difference between the timestamps of each first and second received BLE advertising packets (i.e., the time elapsed between receiving the first and the second BLE advertising packets) is lower than a predetermined waiting time. In case of positive result, the retrieval may be further performed. This may be useful when assessing that the receiving of two or more BLE advertising packets is close enough (in time), thus determining that the subsequent communication in connected mode may be reliable enough, thus ensuring that the subsequent retrieval may not be likely to be interrupted. Furthermore, as in the case of the received first BLE packet, a timestamp corresponding to the second BLE packet may be generated at the computing device (for example, upon arrival of the second BLE packet to the computing device), or it may be obtained from the second BLE packet (i.e., the timestamp being generated by the sensor at the time that the measurement or measurements corresponding to the vital sign data packet were performed).

According to an example, the received BLE advertising communication packet may be embedded in an Eddystone frame.

More specifically, Eddystone is a Google protocol specification that defines a Bluetooth Low Energy (BLE) message format for proximity beacon messages. It describes several different frame types that can be used individually or in combinations to create beacons that can be used for a variety of applications.

Eddystone frames carry sensor information (for sensing the temperature and/or humidity of the device itself), which makes it very useful for Internet of Things.

The common frame PDU (protocol data unit) types and individual service data byte arrangements for Eddystone frame formats are:.

In Eddystone protocol, the "TLM" frame indicates that the frame is providing telemetry from a device. The data packet specification may be as follows:.

More precisely, according to an example, the two existing bytes found within an Eddystone TLM frame, designed to send the beacon temperature, may be used to send a vital sign data packet comprising data related to, for example, body temperature of the patient. Therefore, the data retrieved from the sensor is sent within an Eddystone TLM frame, thus maintaining device interoperability.

This way, by using the telemetry part of an Eddystone frame to send a vital sign packet, such as a measurement of the vital sign sensor (for example, temperature measurement from the sensor), the format of the frame remains the same, and a while a vital sign measurement can be extracted by any computing device receiving the BLE advertising communications packet. Furthermore, Eddystone remains compatible with any operating system, thus ensuring interoperability with any type of computing device (such as, for example, different types of smartphones using different operating systems). Also, Eddystone frames may be used for sending BLE advertising communications packets, while a dedicated protocol may be used to retrieve other packets from the vital sign sensor when a BLE connection in connected mode is established.

Alternatively, other BLE advertising communication packets could likewise be sent using iBeacon protocol.

According to another aspect of the present disclosure, a computing device for remote monitoring of a vital sign of a patient is presented, the computing device comprising:.

The computing device may comprise a connection to a BLE advertising communication packets repository. Such repository may be, for example, found within a server in the cloud, or within the internal memory of the computing device (for example, within the internal memory of a smartphone). Furthermore, the repository may comprise at least one timestamp related to at least one BLE advertising communication packet previously received by the computing device.

Furthermore, according to another aspect of the present disclosure, a computer program is presented comprising program instructions for causing a computing device to perform the previously described method of remote monitoring of a vital sign of a patient. Also, in an example, the computer program may be embodied on a storage medium, or carried on a carrier signal.

According to an example of the present disclosure, as seen in <FIG>, a system <NUM> for monitoring the vital sign of a patient is presented. More precisely, the system <NUM> is configured to monitor the body temperature of a patient, and it comprises a vital sign sensor <NUM>, and a computing device <NUM>, which is a smartphone. Both the sensor <NUM> and the smartphone <NUM> comprise each a Bluetooth Low Energy (BLE) communications module, thus being able to communicate between each other using a BLE protocol.

In this example, as seen in <FIG>, the vital sign sensor <NUM> is a body temperature sensor comprising a holding cuff <NUM>, which can be placed and adjusted in the axillary area of the patient, and a sensing element device <NUM>, which can be attached to the holding cuff in order to be placed in the axillary area, to perform a continuous measurement of the body temperature in the axillary area. Furthermore, the vital sign sensor <NUM> comprises a housing, and within the housing it further comprises a battery <NUM> to provide energy to the sensor, a controller <NUM> to manage the performance of the sensor <NUM>, a BLE communications module <NUM>, and an internal memory <NUM>, connected to the controller, to store measurements performed by the sensing element device <NUM>.

More specifically, in this example, the sensor <NUM> is provided with an internal memory <NUM> where it stores data related to temperature measurements obtained by the sensing element device <NUM>, in a periodic continuous way. The data stored within the internal memory <NUM> is structured using a header section, a data section, and a tail section, wherein the header and the tail section provide the temperature data. They also allow to differentiate the data corresponding to different temperature measurements, in case there are more than one.

The header comprises several fields, which are mainly START, TIMESTAMP (UTC date and time at which the start or stop recording is made), GUID (a field to uniquely identify the recording), STOP (which allows to identify when a capture of the measurement ends), and TIME SINCE LAST CAPTURE (time elapsed between the last measurement and the capture stop), among others. Thus, each different temperature measurement has a corresponding timestamp, related to the time when the measurement was performed.

More precisely, in this example, each time the sensing element device <NUM> of the vital sign sensor <NUM> obtains data related to a temperature measurement of the patient, the data is stored within the internal memory <NUM> of the sensor <NUM>, and also, by means of the controller <NUM> and the BLE communications module <NUM>, said data is embedded within a BLE advertising communication packet and further broadcasted by the vital sign sensor <NUM>.

In the present example, as seen in <FIG>, the smartphone <NUM> is further connected to a cloud <NUM>, via an Internet connection. Also, a server <NUM> is also connected to the cloud <NUM>. The server <NUM> allows monitoring data obtained by the smartphone <NUM>, or to manage the smartphone <NUM> remotely.

Furthermore, <FIG> depicts an example of a method of remote monitoring of a vital sign of a patient according to the present disclosure. More precisely, the method is performed by the smartphone <NUM>, and it comprises the steps of:.

More precisely, the sensing element device <NUM> of the sensor <NUM> obtains a temperature measurement from the patient, and the controller <NUM> of the sensor <NUM> embeds the data related to the temperature measurement within a BLE Eddystone advertising communication packet and sends the packet using the BLE communications module <NUM> of the sensor <NUM>. This way, when the patient is within reach of the smartphone, the smartphone receives the packet through such communication in advertising mode, sent by the sensor <NUM>.

Afterwards, the following step is performed:.

In this case, the smartphone <NUM>, in an internal memory (not pictured), has stored the last BLE advertising communication packet received before the actual packet, with its corresponding timestamp. Such timestamps (the one corresponding to the present packet and the one corresponding to the packet last received by the smartphone) are compared, and a difference of time between them is determined. Such difference of time is the amount of time elapsed between the last received packet by the smartphone <NUM> and the present packet received by the smartphone <NUM>.

Then, a further step is performed depending on the resulting difference of time (or time elapsed):.

Such BLE packet is a request to the controller <NUM> of the sensor <NUM> to establish a subsequent BLE communication in connected mode between the smartphone <NUM> and the sensor <NUM>. This may be performed by sending a specific BLE advertising mode request using a specifically designed BLE protocol, with instructions for the sensor <NUM>. In response, the sensor <NUM>, by means of its controller, may establish a BLE communication in connected mode between itself and the smartphone <NUM>.

Furthermore, after establishing the BLE communication in connected mode between the smartphone <NUM> and the sensor <NUM>, a further step is performed:.

Such packets are retrieved from the internal memory <NUM> of the sensor <NUM>, by indexing the packets of data corresponding to measurements obtained by the sensor in between the last received measurement stored within the smartphone <NUM>, and the present measurement received by the smartphone <NUM>. This way, all the data which has been continuously sent in BLE advertising communication packets by the sensor <NUM>, but the smartphone <NUM> has not received due to, for example, being out of reach of the sensor <NUM>, are sent through a BLE communication in connected mode from the sensor's <NUM> internal memory <NUM> (using the BLE communications module <NUM>) to the smartphone <NUM>.

More precisely, the smartphone <NUM> may compare the timestamp of the present BLE advertising packet with a plurality of timestamps from previously received BLE advertising packets received by the smartphone. This way, the frequency of reception of the BLE advertising packets from a sensor may be determined, thus being also able to determine a pattern of availability of the sensor <NUM>. For example, it may be determined that from 9pm to 8am, the patient sleeps and his/her body substantially blocks the signals sent by the sensor <NUM>. This may be useful in order to save even more battery of the sensor, by establishing that the sensor may be saving the periodical temperature measurements within its internal memory <NUM>, while not sending BLE advertising packets with data related to said temperature measurements. This way, the sensor can start sending current BLE advertising packets at the set time (from 8am onwards), so the smartphone <NUM> can perform the method of the present disclosure, and retrieve all the data related to measurements performed between 9pm and 8am, while energy has been saved during the night by the sensor <NUM> not sending any BLE advertising packet.

Furthermore, the smartphone <NUM> is also connected through the cloud <NUM>, to a computer server <NUM>. Thus, the smartphone <NUM> can periodically send all the data related to temperature measurements compiled from the sensor <NUM>, to the computer server <NUM>. This way, for example, a doctor is able to monitor the temperature of the patient remotely and determine a further treatment, combining the data related to temperature measurements of the patient with other data related to the patient. More precisely, the doctor can, for example, connect to the computer server <NUM> with a further smartphone or via website, to monitor the temperature or other data related to the patient.

Also, <FIG> depicts the structure of BLE packets. More precisely, a BLE packet <NUM> comprises a Preamble section <NUM> (of <NUM> Byte), an Access section <NUM> (of <NUM> Bytes), a Packet Payload <NUM> (of variable length) and a CRC section <NUM> (of <NUM> Bytes). The Packet section <NUM> embeds a Header section <NUM> (of <NUM> Bytes) and a Payload section <NUM> (of variable length). The Packet section <NUM> is also known as the Protocol Data Unit (PDU), and depending on the communication mode, it may vary its length and its content. More specifically, two different types of PDUs are possible within BLE: the Advertising Channel PDU (used in advertising mode communications) and the Data Channel PDU (used in connected mode communications).

As seen in <FIG>, each PDUs have the same length of Header section (<NUM>), which indicate which type of PDU is embedded within the Packet Payload <NUM>.

Furthermore, in Advertising Channel PDU, the Payload section <NUM> comprises an AdvA section <NUM> (which corresponds to <NUM> Bytes comprising the Broadcast Adress), and an AdvData section <NUM> (which corresponds to a variable length of Bytes comprising the Broadcast Data).

In advertising mode communications, wherein the Advertising Channel PDU is used, it is within the AdvData section <NUM> that a plurality of Broadcast Data is comprised, which is usually known as Advertisement data types. Such Advertisement data types are a plurality of possible data structures with a specific function each.

Also, in another example, more than one computing devices may be found within the system (for example a first zone receiver and a second zone receiver), and the described method may be performed in parallel by both (for example, if the patient moves around an area covered by both receivers). In such case, both receivers may be connected to the same computer server through a cloud, and in case any duplicate data may be retrieved by both receivers, redundant data may be discarded by the computer server when compiling all the data related to temperature measurements obtained by the sensor worn by the patient.

An example of a practical situation wherein the system may be used may be in a Hospital floor, wherein a vital sign (for example, the body temperature) of a plurality of patients has to be monitored, and in order to do so, each patient may wear a temperature sensor as the ones previously described according to the present disclosure. Furthermore, the Hospital floor may have a plurality of computing devices such as zone receivers, installed in different positions within the floor, which may be configured to receive BLE advertising communication packets from any sensor worn by any patient.

In this example, whenever one or more patients move around the Hospital floor, some zone receivers may receive the BLE advertising packets sent by each sensor, while others may stop receiving such packets (because, for example, the sensor may be move out of reach from the receiver). This way, whenever a receiver loses BLE advertising packets from a sensor, and after a period of time it starts receiving BLE advertising packets from the same sensor (for example, the user has moved to another area of the Hospital floor, and come back to his original area), the zone receiver may retrieve the data related to measurements performed by the sensor while the sensor was out of the receiver's reach. By using several zone receivers, a redundancy of the measurements may be accomplished, thus ensuring no data is lost. However, if the zone receivers are connected to a central server (through a data cloud), the measurements of each sensor may also be available to other receivers, thus not being necessary to a certain receiver to retrieve data related to certain measurements sent while a sensor was out of reach of said receiver. Furthermore, all measurements may be available in real time, and less retrievals of measurements performed while sensors are out of reach may be necessary to be performed by some of the receivers. Therefore, an extra saving of energy may be achieved by using such configuration.

Furthermore, once connectivity between the sensor and receiver device is restored, the data stored in the internal memory can be retrieved from the sensor by the receiver device in an additional way, by retrieving the vital sign data packets in a periodic and automatic way, with configurable frequency (for example, each hour, if a connected mode type of communication can be established). On-demand retrievals performed by a user may also be possible. In this example, when the temperature data retrieval using a connected mode communication is complete, the data is sent to the cloud via an internet connection.

In addition, in this example, the system can also issue alarms when a predefined body temperature limit is exceeded.

Claim 1:
A method of remote monitoring of a vital sign of a patient, performed by a computing device (<NUM>) comprising a BLE communication module to communicate with a vital sign sensor (<NUM>), the method comprising the steps of:
• Receiving a first BLE advertising communication packet comprising a vital sign data packet, from the sensor (<NUM>);
• Generating a timestamp for the received first BLE advertising communication packet;
• Performing a first time verification of if the difference between the generated timestamp and a stored timestamp of a previously received BLE advertising communication packet is higher than a predetermined waiting time:
∘ In case of positive result:
▪ Sending a BLE packet from the computing device (<NUM>) to the vital sign sensor (<NUM>), to establish a BLE communication in connected mode between the vital sign sensor (<NUM>) and the computing device (<NUM>);
▪ Retrieving, using the BLE communication in connected mode, a plurality of vital sign data packets from the sensor (<NUM>), wherein the packets correspond to timestamps with values between the generated timestamp and the stored timestamp.