Health monitoring method, system and server

Abstract

This application relates to the field of health monitoring technology, and discloses a health monitoring method, a health monitoring system, and a server. The system is applied to a first server, which manages multiple wearable devices. These first servers are each communicatively connected to a second server. The method includes: calculating the historical average value of various status data collected by the wearable devices; calculating the ratio of the current status data to the historical average value; calculating a status health value based on preset weights and ratios; and uploading the status health value to the second server. When the status health value falls within an abnormal threshold range, the second server identifies a target wearable device and sends a distress signal to the target wearable device through the corresponding first server. Through this method, when a wearable device detects an abnormal situation in the wearer, it can request assistance from other wearable devices through the second server, thereby ensuring that the wearer receives timely help.

Description

Technical Field

[0001] This application relates to the field of health monitoring technology, specifically to a health monitoring method, a health monitoring system, and a server. Background Technology

[0002] In recent years, people have paid more and more attention to their health. Wearable devices such as smartwatches and smart bracelets can collect the wearer's status data in real time and monitor various physical indicators of the wearer, which can help prevent diseases and prevent the occurrence of emergencies.

[0003] However, when existing wearable devices detect an abnormal situation in the wearer, they usually send a help message to the emergency contact set in advance on the wearable device. When the wearer's emergency contact is far away from the wearer, or when no emergency contact is set in the wearable device, the emergency contact may not be able to reach the wearer's location in time, or there may be no emergency contact to ask for help, which may result in the wearer not being able to get help in time. Summary of the Invention

[0004] In view of the above problems, this application provides a health monitoring method, a health monitoring system, and a server to solve the problem in the prior art that when a wearable device detects an abnormal situation in the wearer, the wearer cannot receive timely assistance.

[0005] According to a first aspect of the embodiments of this application, a health monitoring method is provided, applied to a first server, the first server being used to manage multiple wearable devices, and the multiple first servers being communicatively connected to a second server respectively; the method includes: acquiring motion patterns, current state data groups, historical state datasets, location information, and identification information uploaded by the wearable devices, wherein the historical motion state dataset includes multiple historical state data groups, and multiple state data points in the current state data group correspond one-to-one with multiple state data points in the historical state data groups; acquiring historical state data groups corresponding to the motion patterns from the historical state dataset, and calculating the historical averages corresponding to each state data point in the historical state data groups. The system calculates the ratio of each state data point in the current state data group to its corresponding historical average value, and obtains the ratio corresponding to each state data point. It then calculates the state health value based on preset weights and the ratios corresponding to each state data point. The system uploads the location information, identification information, and state health value to the second server, so that when the state health value is within an abnormal threshold range, the second server determines the target wearable device and the first server corresponding to the target wearable device based on the location information and a preset distance threshold, and sends a distress message to the first server corresponding to the target wearable device based on the location information and identification information, so that the distress message is sent to the target wearable device through the first server corresponding to the target wearable device.

[0006] In one optional approach, there are multiple preset weights, and each preset weight corresponds one-to-one with each state data. The state health value is calculated based on the ratio between the preset weight and the corresponding state data. Specifically, this includes: calculating the absolute value of the difference between the preset state threshold and the ratio corresponding to each state data to obtain the parameter corresponding to each state data; calculating the state value corresponding to each state data based on the parameter and the preset weight, and calculating the state health value based on the state value.

[0007] In one optional approach, after calculating the absolute value of the difference between the preset state threshold and the ratio corresponding to each state data to obtain the parameters corresponding to each state data, the method further includes: obtaining the preset maximum threshold parameter corresponding to each state data; calculating the ratio of the parameter corresponding to each state data to the maximum threshold parameter to obtain the corrected parameter corresponding to each state data.

[0008] According to a second aspect of the embodiments of this application, a health monitoring method is provided, applied to a second server, the second server being used to communicate with multiple first servers, and each first server managing multiple wearable devices; the method includes: acquiring location information, identification information, and health status values ​​corresponding to each wearable device uploaded by the multiple first servers, wherein the health status values ​​are acquired by the first servers according to the health monitoring method described in the first aspect above; if the health status value corresponding to the wearable device is within an abnormal threshold range, then determining a target wearable device and its corresponding first server based on the location information and a preset distance threshold corresponding to the wearable device, and sending a help request to the first server corresponding to the target wearable device based on the location information and identification information corresponding to the wearable device, so as to send the help request to the target wearable device through the first server.

[0009] In one optional approach, the target wearable device and its corresponding first server are determined based on the location information of the wearable device and a preset distance threshold. Specifically, this includes: identifying wearable devices whose health status is within an abnormal threshold range as wearable devices to be rescued; identifying multiple wearable devices whose health status is within a normal threshold range as candidate wearable devices; calculating the distance between each candidate wearable device and the wearable device to be rescued based on the location information of the wearable device to be rescued and the location information of each candidate wearable device; identifying candidate wearable devices whose distance is less than the preset distance threshold as target wearable devices, and determining the first server corresponding to the target wearable device based on the identification information of the target wearable device.

[0010] In one optional approach, after sending a help request to a first server corresponding to the target wearable device based on the location and identification information of the wearable device, the method further includes: if a confirmation help request is received from the first server corresponding to the target wearable device within a first preset time, then the location information of the target wearable device uploaded by the first server corresponding to the target wearable device is acquired in real time; the target distance is calculated based on the location information of the target wearable device and the location information of the wearable device to be rescued; after a second preset time, if the target distance is greater than a preset threshold, a new target wearable device and its corresponding first server are determined based on the distance between each candidate wearable device and the wearable device to be rescued; and a help request is sent to the first server corresponding to the new target wearable device based on the location and identification information of the wearable device to be rescued, so that the help request is sent to the new target wearable device through the first server corresponding to the new target wearable device.

[0011] In one alternative approach, if no confirmation of rescue is received from the wearable device to be rescued via its corresponding first server within a third preset time period, a new target wearable device and its corresponding first server are determined based on the distance between each candidate wearable device and the wearable device to be rescued; and a request for help is sent to the first server corresponding to the new target wearable device based on the location and identification information of the wearable device to be rescued, so that the request for help is sent to the new target wearable device through the first server corresponding to the new target wearable device.

[0012] In one optional approach, after sending a distress request to a first server corresponding to the target wearable device based on the location and identification information of the wearable device, the method further includes: if no confirmation of assistance is received from the first server within a first preset time, determining a new target wearable device and its corresponding first server based on the distance between each candidate wearable device and the wearable device to be rescued; and sending a distress request to the first server corresponding to the new target wearable device based on the location and identification information of the wearable device to be rescued, so that the distress request is sent to the new target wearable device through the first server corresponding to the new target wearable device.

[0013] According to a third aspect of the embodiments of this application, a health monitoring system is provided. The system includes a second server and multiple first servers communicatively connected thereto. Each first server is used to manage multiple wearable devices. The first servers are used to acquire motion patterns, current status data sets, historical status datasets, location information, and identification information uploaded by the wearable devices. The historical motion status dataset includes multiple historical status data sets, and multiple status data points in the current status data set correspond one-to-one with multiple status data points in the historical status data sets. The first servers are also used to acquire historical status data sets corresponding to motion patterns from the historical status dataset, calculate the historical average value corresponding to each status data point in the historical status data set, and calculate the ratio of each status data point in the current status data set to its corresponding historical average value. The first server calculates the state health value based on the preset weights and the ratios of the various state data, and uploads the location information, identification information, and state health value to the second server. The second server obtains the location information, identification information, and state health value of each wearable device uploaded by the first server. When the state health value of a wearable device is within an abnormal threshold range, the second server determines the target wearable device and its corresponding first server based on the location information and a preset distance threshold, and sends a distress message to the first server corresponding to the target wearable device based on the location information and identification information of the wearable device. The first server corresponding to the target wearable device sends the distress message to the target wearable device.

[0014] According to a fourth aspect of the embodiments of this application, a server is provided, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the health monitoring method of the first aspect, or the processor executes the computer program to implement the health monitoring method of the second aspect.

[0015] This application embodiment calculates the wearer's current health status by comparing the current state data collected by the wearable device with the historical state data corresponding to the same movement. Regardless of the number of state data items collected by the wearable device or the specific state data, multiple state data items can be merged into a single health status value. On the one hand, this ensures that the data received by the second server is a unified health status value, preventing the influence of different hardware on the wearable device and ensuring that wearable devices from different manufacturers can also cooperate online. When the wearable device detects an abnormal situation in the wearer, it can seek help from the target wearable device through the second server, thereby ensuring that the wearer of the wearable device can receive timely assistance. On the other hand, the first server only needs to upload the health status value to the second server, without uploading the specific state data, which can prevent the leakage of users' critical data information and ensure information security.

[0016] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0017] The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A structural block diagram of the health monitoring system provided in an embodiment of this application is shown; Figure 2 A flowchart illustrating the health monitoring method provided in an embodiment of this application is shown; Figure 3 A flowchart illustrating a health monitoring method according to another embodiment of this application is shown; Figure 4 A schematic diagram of the server structure provided in an embodiment of this application is shown. Detailed Implementation

[0018] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. Although exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein.

[0019] Wearable devices refer to smart electronic devices that can be worn directly on the body, such as smartwatches, smart bracelets, smart glasses, and smart clothing. These electronic devices typically integrate multiple sensors and smart functions to monitor and record the user's physiological data, movement status, environmental information, etc., and provide real-time feedback and information notifications.

[0020] When a wearable device detects an emergency, it can send a distress message to the wearer's emergency contact via a pre-set emergency contact method. However, if the wearer is far from their emergency contact, or if the device lacks a pre-set emergency contact method, the emergency contact may not be able to reach the wearer immediately after receiving the distress message. This could lead to more serious physical harm or even death due to the lack of timely assistance.

[0021] Based on this, this application provides a health monitoring method. A first server acquires data such as motion patterns, status data sets, location information, and identification information uploaded by a wearable device, calculates the wearer's health status based on this data, and uploads the health status to a second server. This allows the second server to promptly match a target wearable device based on the location information when the wearer's health status becomes abnormal, and sends a distress message to the target wearable device through the first server corresponding to the target wearable device. This ensures that if the wearer encounters an emergency and does not have time to call for help, they can seek help online through the wearable device.

[0022] In this approach, the first server can monitor the wearer's health status in a timely manner through data collected by the wearable device. When the wearer encounters an emergency during exercise, the first server can send a help request to other wearable devices through the second server to achieve online mutual assistance between wearable devices, thereby ensuring that the wearer can receive assistance in case of an emergency.

[0023] Furthermore, to protect user privacy, the first server does not upload all data collected by the wearable device to the second server. Instead, it only uploads data such as the wearer's health status (i.e., the results obtained by the first server from analyzing the data monitored by the wearable device), location information, and identification information. This ensures that the second server can promptly provide online assistance based on the wearer's location and identification information if the wearer's health condition becomes abnormal. However, because wearable devices from different manufacturers may be equipped with different sensors, the data they collect and the methods they use to determine the wearer's health status may also differ. This can lead to discrepancies in the data uploaded from the first server to the second server, potentially preventing the second server from accurately matching the target wearable device based on the wearer's health condition.

[0024] Therefore, in order to ensure that the second server can accurately assist wearers of other wearable devices in case of emergencies, the health monitoring method provided in this application involves the first server, after obtaining the motion mode, current status data set, and historical status dataset uploaded by the wearable device, first retrieving the historical status data set corresponding to the motion mode from the historical status dataset, calculating the historical average value of each status data in the historical status data set, then calculating the ratio of each status data in the current status data set to the historical average value, and then calculating the wearer's health status value according to the preset weights and the ratios corresponding to each status data. Finally, the health status value is uploaded to the second server so that the second server can determine the wearer's health status based on the health status value.

[0025] In this approach, regardless of the number or specific data points collected by the wearable device, the wearer's current health status can be calculated by comparing the currently collected data with historical data for the same activity. This ensures that the data received by the second server is a consistent health status, preventing the influence of hardware differences on wearable devices and enabling online collaboration between wearable devices from different manufacturers. When a wearable device detects an abnormality in the wearer, it can request assistance from other wearable devices through the second server, ensuring the wearer receives timely help. Furthermore, merging multiple data points into a single health status value prevents the leakage of critical user data, ensuring information security.

[0026] According to a first aspect of the embodiments of this application, a health monitoring system is provided, such as... Figure 1 As shown, Figure 1 A structural block diagram of a health monitoring system is shown. The health monitoring system includes a second server 1 and multiple first servers 2 connected to it by signals. Each first server 2 is used to manage multiple wearable devices 3.

[0027] Wearable devices 3 integrate multiple high-precision sensors such as temperature, humidity, acceleration, and GPS, primarily used to monitor and record relevant data of the wearer. For example, wearable devices can collect status data such as heart rate, total exercise time, steps, calories, temperature, pace, stride length, frequency, and distance; geographical data such as altitude and slope; and location information such as longitude and latitude. Wearable devices 3 can be smartwatches, smart bracelets, smart glasses, smart clothing, etc.

[0028] The first server 2 is mainly used to store and process data uploaded by the wearable device 3. As an example, the first server 2 can obtain relevant data collected by the wearable device 3 through the application corresponding to the wearable device 3. First, the application corresponding to the wearable device 3 is downloaded on a smart device such as a smartphone, tablet, or computer. Then, after the wearable device 3 collects relevant data from the wearer, it can interact with the smart device through communication protocols such as Bluetooth and WIFI, and upload the collected relevant data to the application on the smart device. Finally, the application on the smart device uploads the relevant data collected by the wearable device 3 to the first server 2 through Internet protocols (such as TCP / IP, HTTP / HTTPS, etc.), so that the first server 2 can determine the wearer's health status based on this relevant data.

[0029] Specifically, the first server 2 is used to obtain the motion mode, current status data group, historical status dataset, location information and identification information uploaded by the wearable device 3. The historical motion status dataset includes multiple historical status data groups, and multiple status data in the current status data group correspond one-to-one with multiple status data in the historical status data group.

[0030] The first server 2 is also used to obtain the historical state data group corresponding to the motion pattern from the historical state dataset, calculate the historical average value corresponding to each state data in the historical state data group, calculate the ratio of each state data in the current state data group to its corresponding historical average value, and obtain the ratio corresponding to each state data.

[0031] The first server 2 is also used to calculate the status health value based on the preset weights and the ratios corresponding to various status data, and upload the location information, identification information and status health value to the second server 1.

[0032] The second server 1 is used to enable online mutual assistance between the wearable devices 3. Specifically, the second server 1 is used to obtain the location information, identification information, and health status value of each wearable device 3 uploaded by multiple first servers 2. When the health status value of the wearable device 3 is within the abnormal threshold range, the second server 1 determines the target wearable device and its corresponding first server based on the location information and a preset distance threshold. Based on the location information and identification information of the wearable device 3, the second server 1 sends a request for help to the first server 2 corresponding to the target wearable device. The first server 2 corresponding to the target wearable device then sends the request for help to the target wearable device, thereby enabling online mutual assistance between the wearable device 3 and the target wearable device.

[0033] The following section provides a detailed description of the health monitoring method applied to the first server 2. For specific details, please refer to [link / reference needed]. Figure 2 , Figure 2 A flowchart of a health monitoring method provided in an embodiment of this application is shown. The method is executed by a first server 2 and includes the following steps: Step S110: Obtain the motion mode, current state data group, historical state dataset, location information and identification information uploaded by the wearable device. The historical motion state dataset includes multiple historical state data groups, and multiple state data in the current state data group correspond one-to-one with multiple state data in the historical state data group.

[0034] The exercise mode refers to the specific activity the wearer is currently engaged in. This exercise mode can be the one selected by the wearer on the wearable device, or it can be identified by the wearer based on the wearer's status data (such as pace, stride length, and cadence). This exercise mode can include outdoor running, outdoor hiking, trail running, marathon, mountaineering, and other similar activities.

[0035] The current status data group consists of status data such as heart rate, HRV, temperature, blood oxygen, and respiratory rate currently collected by the wearable device. Specifically, when the wearer turns on the exercise mode, the wearable device can collect data every certain period of time (e.g., 5 seconds) and communicate with the application on the smart device via WIFI, Bluetooth, etc., so that the application can obtain the wearer's status data and upload it to the first server 2.

[0036] The historical state dataset is historical data collected by wearable devices. This historical state dataset includes multiple sets of historical state data, which may include state data sets collected under different sports modes.

[0037] Both the current status data group and the historical status data group can include any of the status data such as heart rate, HRV, temperature, blood oxygen, and respiratory rate. However, the current status data group and the historical status data group of the same wearable device should include the same status data, that is, multiple status data in the current status data group correspond one-to-one with multiple sets of status data in the historical status data group.

[0038] The state data included in the current state data group and the historical state data group are determined by the sensors integrated into the wearable device. For example, if wearable device A can only monitor heart rate and temperature, then the current state data group and the historical state data group collected by wearable device A will only include heart rate and temperature. If wearable device B can only monitor heart rate and respiratory rate, then the current state data group and the historical state data group collected by wearable device B will only include heart rate and respiratory rate.

[0039] Location information is used to characterize the wearer's current location. This location information is typically the longitude and latitude detected by the wearable device through sensors such as GPS. Identification information is a unique identifier for the wearable device, used by the first and second servers to identify and distinguish each wearable device. Specifically, it can be the wearable device's MAC address, device serial number, or other identification information such as a number or string generated by the first or second server for the wearable device.

[0040] Step S120: Obtain the historical state data group corresponding to the motion pattern from the historical state dataset, and calculate the historical average value corresponding to each state data in the historical state data group.

[0041] Among them, the historical state data group can be the state data group collected when the wearer starts the same sports mode in the history record, or it can be the data collected after the wearer starts the sports mode. As an example, assuming that the wearable device collects data every 5 seconds, after the wearer starts the sports mode, the wearable device collects the current state data group, and all the previously collected state data groups can be used as the historical state data group corresponding to the sports mode.

[0042] Server 2 can calculate the historical average value corresponding to each status data in the historical status data group. Specifically, it can use the following formula for calculation:

[0043] in, It is a specific status data item (such as heart rate, temperature, blood pressure, blood oxygen, respiratory rate, etc.) in the wearer's historical status data group. It is the historical average value of a certain status data in the historical status data group, that is, the average value of a certain status data of the wearer within a certain time range.

[0044] As an example, within a certain time frame, a wearable device uploads multiple status data points to a first server, such as blood oxygen, blood pressure, and heart rate, as the wearer's status data in exercise mode. These are stored as historical status data groups, with heart rates in each historical status data group being 118, 102, 103, 106, 108, 102, 106, 95, 110, and 100, respectively. The historical average heart rate is then calculated as follows:

[0045] Step S130: Calculate the ratio of each state data in the current state data group to its corresponding historical average value to obtain the ratio corresponding to each state data.

[0046] Because the parameters fed back by the body functions of different wearers vary, the data collected by the wearable device also varies greatly when different wearers perform the same exercise. In order to make the first server's assessment of the wearer's health status more accurate, the first server can compare the wearer's current status data with the average of historical status data to reflect the fluctuation of various status data. In this way, the fluctuation of status data can more accurately reflect the wearer's current health status and avoid the impact of differences in the body functions of different wearers on the calculated health status.

[0047] Specifically, the ratios corresponding to each state data point can be calculated using the following formula:

[0048] in, This represents the ratio of a specific status data point in the wearer's current status data set to its corresponding historical average. This indicates a specific piece of state data within the current state data group.

[0049] As an example, suppose the heart rate in the current state data set is 100, and the historical average heart rate is 105. Then the ratio corresponding to the heart rate is:

[0050] Step S140: Calculate the health status value based on the preset weights and the ratios corresponding to each status data.

[0051] The preset weights are used to weight the various state data, ensuring that the final health value falls within the range of 0 to 1. This allows the first server to combine the ratios of the various state data into a single health value regardless of the state data collected by the wearable device. Specifically, multiple preset weights can be used, each corresponding to a specific state data point. Step S140 may include the following steps (steps S141 to S142): Step S141: Calculate the absolute value of the difference between the preset state threshold and the ratio corresponding to each state data, and obtain the parameters corresponding to each state data.

[0052] The status data generally includes two types of abnormal situations: abnormal rise and abnormal fall. When the status data is close to the historical average, the ratio of the status data will be close to 1. Therefore, the preset status threshold can be set to 1.

[0053] When the status data shows an abnormal increase or decrease, the corresponding ratio will become either larger or smaller. Taking heart rate as an example, assuming the historical average heart rate is 105, when the wearer's heart rate abnormally rises to 185, the corresponding ratio will be... At this point, the ratio corresponding to heart rate will become particularly large; while when the wearer's heart rate abnormally drops to 32, the ratio corresponding to heart rate will be... At this point, the ratios corresponding to heart rate will become very small. However, the difference between them and the preset state threshold will be relatively large. Therefore, it is possible to use... These represent the parameters corresponding to each state data item.

[0054] Furthermore, to ensure the accuracy of the parameters corresponding to each state data point, after calculating the parameters, it is necessary to correct these parameters so that the range of the parameters corresponding to each state data point is within the interval of 0 to 1. This ensures that the final state health value can always remain within the interval of 0 to 1. This can be achieved by normalizing the parameters corresponding to each state data point, or by processing the state parameters separately based on the maximum threshold parameter of each state parameter. As an example, after step S141, the method further includes the following steps (steps S141a to S141b): Step S141a: Obtain the maximum threshold parameter corresponding to each preset state data.

[0055] Step S141b: Calculate the ratio of the parameter corresponding to each state data to the maximum threshold parameter to obtain the corrected parameter corresponding to each state data.

[0056] First, the maximum threshold parameter corresponding to each state data point is obtained. This maximum threshold parameter represents the maximum possible fluctuation range of each state data point, and it is set based on experience. Then, the ratio of the parameter corresponding to each state data point to the maximum threshold parameter is used to correct the parameter corresponding to each state data point to a range of 0 to 1.

[0057] Through steps S141a to S141b, the parameters corresponding to each state data can be corrected to the range of 0 to 1, thereby normalizing the parameters corresponding to each state data. This ensures that the state health value calculated subsequently using the parameters corresponding to each state data is also within the range of 0 to 1, which helps improve the accuracy of the data.

[0058] Step S142: Calculate the state value corresponding to each state data according to the parameters and preset weights of each state data, and calculate the state health value according to the state value.

[0059] The state value can be obtained by multiplying the parameters corresponding to each state data point with a preset weight, while the state health value can be obtained by accumulating the state values ​​corresponding to each state data point. As an example, the state health value... The calculation formula is as follows:

[0060] in, The parameter corresponding to the i-th state data item. Let be the maximum threshold parameter corresponding to the i-th state data item. This represents the preset weight corresponding to the i-th state data item. Since the state data collected by different wearable devices may differ, in order to ensure the accuracy of the state health value, the sum of the preset weights corresponding to all state data should be set to 1, so as to ensure that the final calculated state health value is within the range of 0 to 1.

[0061] As an example, assuming that the maximum threshold parameter for each status data item on the wearable device is 100%, and the preset weight for each status data item is configured to 50%, when the wearable device collects status data where the parameter corresponding to heart rate is 95% and the parameter corresponding to temperature is 80%, then it can be calculated that:

[0062] This refers to the wearer's overall health status when engaging in a particular sport.

[0063] Through steps S141 to S142, the first server can merge the ratios corresponding to each status data into a single status health value using preset weights. Regardless of what the status data collected by the wearable device is or how many items there are, all the status data collected by the wearable device can be merged into a single status health value, and the range of this status health value is within the range of 0 to 1, so that the data subsequently uploaded by multiple first servers to the second server can remain consistent.

[0064] Furthermore, different exercise modes have different effects on state data such as heart rate, blood pressure, and respiratory rate. For example, aerobic exercise and high-intensity training require more oxygen to meet the energy needs of muscles, which prompts the respiratory system to work faster to provide enough oxygen. That is, during aerobic exercise and high-intensity training, the wearer's respiratory rate will change drastically between exercise and rest. On the other hand, low-intensity or static exercise does not significantly increase the body's oxygen demand as much as high-intensity exercise. Therefore, when the wearer is engaged in low-intensity or static exercise, the wearer's respiratory rate will be relatively stable and will not change drastically.

[0065] The first server can pre-store the weights of various status data corresponding to different operating modes. For example, the weights can be set according to the fluctuation of status data under normal conditions. For status data that fluctuates greatly under normal conditions, a smaller weight can be set, and for status data that fluctuates less under normal conditions, a larger weight can be set. Alternatively, the weights can be set according to the importance of the status data. For data such as heart rate and blood pressure, a larger weight can be set, and for data such as temperature and respiratory rate, a smaller weight can be set.

[0066] Step S150: Upload the location information, identification information, and health status value to the second server so that when the health status value is within the abnormal threshold range, the second server determines the target wearable device and the first server corresponding to the target wearable device based on the location information and the preset distance threshold, and sends a help request to the first server corresponding to the target wearable device based on the location information and identification information, so that the help request is sent to the target wearable device through the first server corresponding to the target wearable device.

[0067] The first server uploads location information, identification information, and health status values ​​to the second server. This allows the second server to determine the wearer's health status based on the health status values ​​and, in the event of an emergency, match the wearer with a target wearable device based on the location information. This enables the second server to proactively request assistance from the wearer of the target wearable device, ensuring timely help for the wearer in an emergency. Specifically, the first and second servers can exchange data via internet protocols such as TCP / IP and HTTP / HTTPS.

[0068] Regarding the specific method of matching target wearable devices based on location information, matching can be performed by setting a preset distance threshold. This involves calculating the distance between the wearable device and other wearable devices, and selecting those closer to the preset distance threshold as the target wearable device. Preferably, the wearable device with the shortest distance can be selected as the target wearable device, allowing the wearer in an emergency to receive faster assistance.

[0069] In the above embodiments, the wearer's current health value is calculated by comparing the current state data collected by the wearable device with the historical state data corresponding to the same movement. Regardless of the number of state data items collected by the wearable device or the specific state data, multiple state data items can be merged into a single health value. On the one hand, this ensures that the data received by the second server is a unified health value, preventing the influence of different hardware on the wearable device and ensuring that wearable devices from different manufacturers can also cooperate online. When the wearable device detects an abnormal situation in the wearer, it can seek help from the target wearable device through the second server, thereby ensuring that the wearer of the wearable device can receive timely assistance. On the other hand, the first server only needs to upload the health value to the second server, without uploading the specific state data, which can prevent the leakage of users' critical data information and ensure information security.

[0070] Furthermore, for a detailed description of the health monitoring method applied on the second server 1, please refer to [link / reference]. Figure 3 , Figure 3 A flowchart of a health monitoring method provided in another embodiment of this application is shown. The method is executed by a second server 1 and includes the following steps: Step S210: Obtain the location information, identification information and health status value of each wearable device uploaded by multiple first servers, wherein the health status value is obtained by the first server according to the health monitoring method described in the above embodiments.

[0071] Step S220: If the health status value of the wearable device is within the abnormal threshold range, the target wearable device and its corresponding first server are determined according to the location information and preset distance threshold of the wearable device. Then, a help request is sent to the first server corresponding to the target wearable device according to the location information and identification information of the wearable device, so that the help request is sent to the target wearable device through the first server.

[0072] Once the second server receives the location information, identification information, and health status value of each wearable device uploaded by the first server, it can filter out abnormal status data in real time through polling. Abnormal status data indicates that the wearer of the wearable device has encountered an emergency. Based on the location information of the wearer who encountered the emergency, the server can help match the wearer with other wearable device users.

[0073] Specifically, the second server can determine whether the wearer of the wearable device has encountered an emergency and needs help from other wearers based on the preset abnormal threshold range. For example, when the health status value is greater than 0.7, the health status value is considered to be abnormal.

[0074] Furthermore, the second server can divide the range of health status values ​​(i.e., the range from 0 to 1) into three threshold ranges to distinguish the wearer's status in three states: normal, warning, and abnormal. For example, if the health status value is less than 0.35 (i.e., the normal threshold range is set to 0 to 0.35), the wearer is determined to be in a normal state; if the health status value is between 0.35 and 0.7, the wearer is determined to be in a warning state; and if the health status value is greater than 0.7 (i.e., the abnormal threshold range is set to 0.7 to 1), the wearer is determined to be in an abnormal state, meaning the wearer has encountered an emergency and urgently needs assistance.

[0075] When the second server detects a wearable device whose health status is within the abnormal threshold range, it can match the nearest target wearable device from all wearable devices managed by the first server based on the location information of the wearable device. Then, it sends a distress message to the target wearable device through the first server corresponding to the target wearable device, so that the wearer of the target wearable device can provide assistance to the wearer whose health status is within the abnormal threshold range upon receiving the distress message.

[0076] Furthermore, to ensure that wearers of wearable devices whose health status is within the abnormal threshold range can receive timely assistance, the second server can also determine the target wearable device and its corresponding first server through the following steps (steps S221 to S224): Step S221: Identify wearable devices whose health status is within the abnormal threshold range as wearable devices to be rescued.

[0077] Step S222: Select multiple wearable devices whose health status is within the normal threshold range as candidate wearable devices.

[0078] Step S223: Calculate the distance between each candidate wearable device and the wearable device to be rescued based on the location information corresponding to the wearable device to be rescued and the location information corresponding to each candidate wearable device.

[0079] Step S224: Identify candidate wearable devices whose distance is less than a preset distance threshold as target wearable devices, and determine the first server corresponding to the target wearable device based on the identification information corresponding to the target wearable device.

[0080] First, during the polling process, the second server can identify wearable devices whose health status is within the abnormal threshold range as wearable devices to be rescued, and identify multiple wearable devices whose health status is within the normal threshold range as candidate wearable devices.

[0081] Next, based on the location information of the wearable device to be rescued and the location information of the candidate wearable devices, the distance between each candidate wearable device and the wearable device to be rescued is calculated. When the location information is longitude and latitude, the second server can calculate the distance between the wearable devices using the Haversine formula, as follows: , , , , , in, and The latitude and longitude are the location information corresponding to the candidate wearable devices. and The latitude and longitude of the location information corresponding to the wearable device in need of rescue. , , , (All measurements are in radians), R is the radius of the Earth (usually taken as an average radius of 6371 kilometers), and the d calculated by the above formula is the distance in kilometers between the candidate wearable device and the wearable device to be rescued.

[0082] Finally, candidate wearable devices located less than a preset distance threshold are identified as target wearable devices. This allows for matching the nearest candidate wearable device to the wearable device in need of rescue, ensuring that the wearer of the candidate device can quickly reach the location of the wearer of the device in need of rescue, thus enabling timely assistance. The wearable device in need of rescue and the target wearable device can be managed by the same primary server or by different primary servers.

[0083] Preferably, the wearable device with the shortest distance can be selected as the target wearable device to ensure that the wearer in an emergency receives faster assistance. Furthermore, multiple preset distance thresholds can be set. If no candidate wearable device is found within the current preset distance threshold, the preset distance threshold can be appropriately increased to further ensure that the wearer of the wearable device awaiting assistance receives timely help.

[0084] Through steps S221 to S224, the wearer of the wearable device awaiting rescue is matched with the nearest target wearable device to ensure timely assistance. This is particularly important in sports such as marathons and group mountaineering, where the nearest target wearable device is typically located near the wearable device awaiting rescue, allowing it to respond immediately. Furthermore, the target wearable device is selected from those with health values ​​within the normal threshold range, ensuring the wearer of the target device is in good health and thus enabling them to provide effective assistance to the wearer of the device awaiting rescue.

[0085] The second server can first send a request for help to the first server corresponding to the target wearable device based on the location and identification information of the wearable device to be rescued. Then, the first server corresponding to the target wearable device will send the request for help to the target wearable device. This avoids direct information interaction between the second server and the wearable device, thereby protecting the privacy of the target wearable device.

[0086] The distress call information may include the location information of the wearable device in need of rescue, ensuring that the target wearable device can accurately reach its location. Additionally, the distress call information may include contact information on the wearable device in need of rescue. This contact information can be the contact information of the wearer of the device in need of rescue, or the contact information of an emergency contact set on the device, allowing the wearer of the target wearable device to contact either the wearer of the device in need of rescue or the emergency contact.

[0087] Furthermore, when there are multiple target wearable devices, the second service can simultaneously send help requests to the first server corresponding to each target wearable device, so that the first server corresponding to each target wearable device simultaneously sends help requests to each target wearable device. Of course, the second server can also send help requests to the first server corresponding to each target wearable device one by one, according to the distance between each target wearable device and the wearable device to be rescued, in order from closest to furthest. For example, after the second server sends help requests to the first server corresponding to the target wearable device with the shortest distance, it waits for a specific time interval. If it does not receive a response message from the target wearable device within this time interval (e.g., a confirmation help message returned by the target wearable device), it sends help requests to the first server corresponding to the second shortest distance target wearable device, and so on, until it receives a response message from the target wearable device.

[0088] In the above embodiments, the second server can obtain data uploaded by multiple first servers, and when it detects that a wearer of a wearable device is encountering an emergency, it can quickly match the wearable device encountering the emergency with a target wearable device. Then, the first server corresponding to the target wearable device sends a help request to the target wearable device, so that the wearer of the wearable device encountering the emergency can seek help from the wearer of the target wearable device. This realizes online mutual assistance between wearable devices and avoids the problem of no one responding to help when the wearer of the wearable device encounters an emergency.

[0089] It should be noted that when the wearable device has emergency contacts or rescue station information set up, it can also automatically contact emergency contacts or rescue stations for help.

[0090] Furthermore, to ensure that the wearer of the wearable device in need of assistance receives timely help, after the second server sends the request for help to the first server, the second server also needs to further determine whether the target wearable device is capable of providing assistance to the wearer of the wearable device in need of assistance. Specifically, after step S220, the method further includes: Step S300: Within a first preset time, detect in real time whether a confirmation help message is received from the first server corresponding to the target wearable device.

[0091] If the second server does not receive confirmation help information from the first server corresponding to the target wearable device within the first preset time, it means that the wearer of the target wearable device has not confirmed that they want to help the wearer of the wearable device to be rescued. It is necessary to re-match the target wearable device for the wearable device to be rescued, that is, to execute step S311.

[0092] Step S311: If no confirmation help information is received from the target first server within the first preset time, then a new target wearable device and its corresponding first server are determined based on the distance between each candidate wearable device and the wearable device to be rescued.

[0093] Step S312: Based on the location information and identification information of the wearable device to be rescued, send a distress message to the first server corresponding to the new target wearable device, so that the distress message can be sent to the new target wearable device through the first server corresponding to the new target wearable device.

[0094] When the target wearable device does not respond to the distress call, the second server can continue to seek help from the next candidate wearable device that is closest to the wearable device in need of help. That is, in addition to the current target wearable device, the next candidate wearable device that is closest to the wearable device in need of help will be identified as the new target wearable device to ensure that the wearer of the wearable device in need of help can receive timely assistance.

[0095] Through steps S311 to S312, when the target wearable device does not respond to the distress message, the second server can quickly seek help from the next candidate wearable device to ensure that the wearer of the wearable device in need of help can receive timely assistance.

[0096] If the second server receives confirmation help information returned by the first server corresponding to the target wearable device within the first preset time, it means that the wearer of the target wearable device confirms to help the wearer of the wearable device to be rescued. At this time, it is necessary to monitor the distance between the target wearable device and the wearable device to be rescued in real time to determine whether the positions of the two are gradually getting closer, so as to prevent the target wearable device from being accidentally touched and returning confirmation help information to the second server, i.e., execute step S321.

[0097] Step S321: Obtain the location information of the target wearable device uploaded by the first server corresponding to the target wearable device in real time.

[0098] Step S322: Calculate the target distance based on the location information of the target wearable device and the location information of the wearable device to be rescued.

[0099] Step S323: After the second preset time, if the target distance is greater than the preset threshold, then a new target wearable device and its corresponding first server are determined based on the distance between each candidate wearable device and the wearable device to be rescued.

[0100] Step S324: Based on the location information and identification information corresponding to the wearable device to be rescued, send a request for help to the first server corresponding to the new target wearable device, so that the request for help is sent to the new target wearable device through the first server corresponding to the new target wearable device.

[0101] When the second server receives the confirmation help information uploaded by the first server corresponding to the target wearable device, it needs to obtain the location information of the target wearable device in real time and calculate the target distance between the target wearable device and the wearable device to be rescued, so as to determine whether the target wearable device and the wearable device to be rescued are gradually getting closer based on the change of the target distance.

[0102] If the target distance is still greater than the preset threshold after the second preset time, it indicates that the confirmation help information received by the second server may have been returned due to the target wearable device being accidentally touched, and the wearer of the target wearable device did not go to the wearer of the wearable device to be rescued. At this time, it is necessary to rematch the target wearable device with a target wearable device. Specifically, the second server can continue to seek help from the next candidate wearable device that is closest to the wearable device to be rescued. That is, in addition to the current target wearable device, the next candidate wearable device that is closest to the wearable device to be rescued is determined as the new target wearable device.

[0103] Through steps S321 to S324, after receiving the confirmation help information returned by the first service corresponding to the target wearable device, the second server monitors the target distance between the target wearable device and the wearable device to be rescued in real time. When it is determined that the target wearable device is not approaching the wearable device to be rescued, the server quickly identifies a new target wearable device to request help, thereby ensuring that the wearer of the wearable device to be rescued can receive timely assistance.

[0104] Furthermore, to ensure that wearers of wearable devices awaiting rescue receive timely assistance, the method includes the following steps: Step S410: If no confirmation of rescue is received from the wearable device to be rescued through its corresponding first server within the third preset time, then a new target wearable device and its corresponding first server are determined based on the distance between each candidate wearable device and the wearable device to be rescued.

[0105] Step S420: Based on the location information and identification information corresponding to the wearable device to be rescued, send a distress message to the first server corresponding to the new target wearable device, so that the distress message can be sent to the new target wearable device through the first server corresponding to the new target wearable device.

[0106] In this system, the second server, in addition to monitoring the distance between the target wearable device and the wearable device to be rescued, can also determine whether someone has already rescued the wearer of the device by detecting whether the request for help on the wearable device to be rescued has been cancelled. Specifically, the second server starts timing after sending the request for help information to the first server corresponding to the target wearable device. If, within a third preset time, the wearable device to be rescued does not upload confirmation of rescue to the second server through its corresponding first server, it can be determined that the wearer of the wearable device to be rescued has not received rescue within the third preset time. The second server then needs to continue to request help from the next candidate wearable device closest to the wearable device to be rescued; that is, in addition to the current target wearable device, the next candidate wearable device closest to the wearable device to be rescued is identified as the new target wearable device.

[0107] Through steps S410 to S420, the second server is able to promptly re-match a new target wearable device to the wearable device awaiting rescue if the rescue has not been confirmed within a specified time, so as to ensure that the wearer of the wearable device awaiting rescue can receive rescue.

[0108] According to a fourth aspect of the embodiments of this application, a server is provided, such as... Figure 4 As shown, Figure 4 The diagram shows a schematic of the server provided in an embodiment of this application. The specific embodiments of this application do not limit the specific implementation of the server.

[0109] The server 4 may include a processor 41 and memory 42.

[0110] The memory 42 is used to store the computer program 43. The memory 42 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device. The computer program 43 may include computer-executable instructions.

[0111] The processor 41 is used to execute the computer program 43 to implement the above-described health monitoring method embodiment applied on the first server, or the processor 41 is used to execute the computer program 43 to implement the above-described health monitoring method embodiment applied on the second server.

[0112] Processor 41 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. Server 4 may include one or more processors of the same type, such as one or more CPUs; or it may include processors of different types, such as one or more CPUs and one or more ASICs.

[0113] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described health monitoring method embodiment applied to a first server, or, when executed by a processor, implements the above-described health monitoring method embodiment applied to a second server.

[0114] This application provides a computer program that can be executed by a processor to implement the above-described health monitoring method embodiment applied to a first server, or the computer program can be executed by a processor to implement the above-described health monitoring method embodiment applied to a second server.

[0115] This application provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described health monitoring method embodiment applied to a first server, or, when executed by a processor, implements the above-described health monitoring method embodiment applied to a second server.

[0116] In the several embodiments provided in this application, any function, if implemented as a software functional module / unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, part or all of the technical solutions of this application can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or other electronic device) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing computer program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0117] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, the embodiments of this application are not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of this application.

[0118] It should be noted that the above embodiments are illustrative of this application and not restrictive, and those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In claims enumerating several means, several units or modules of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

[0119] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A health monitoring method, characterized in that, The method is applied to a first server, which manages multiple wearable devices, and the multiple first servers are respectively communicatively connected to a second server; the method includes: The wearable device uploads motion modes, current state data groups, historical state datasets, location information, and identification information. The historical motion state dataset includes multiple historical state data groups, and multiple state data in the current state data group correspond one-to-one with multiple state data in the historical state data group. Obtain the historical state data group corresponding to the motion pattern from the historical state dataset, and calculate the historical average value corresponding to each state data item in the historical state data group; Calculate the ratio of each state data in the current state data group to its corresponding historical average value to obtain the ratio corresponding to each state data; The health status value is calculated based on the preset weights and the ratios corresponding to each of the aforementioned status data. The location information, the identification information, and the health status value are uploaded to the second server, so that when the health status value is within an abnormal threshold range, the second server determines the target wearable device and the first server corresponding to the target wearable device based on the location information and a preset distance threshold, and sends a help request to the first server corresponding to the target wearable device based on the location information and the identification information, so that the help request is sent to the target wearable device through the first server corresponding to the target wearable device.

2. The health monitoring method according to claim 1, characterized in that, The preset weights include multiple ones, and each preset weight corresponds one-to-one with each of the state data. The step of calculating the health status value based on preset weights and the ratios corresponding to each of the status data specifically includes: Calculate the absolute value of the difference between the preset state threshold and the ratio corresponding to each state data item to obtain the parameter corresponding to each state data item; The state value corresponding to each state data is calculated based on the parameters and the preset weights corresponding to each state data, and the state health value is calculated based on the state value.

3. The health monitoring method according to claim 2, characterized in that, After calculating the absolute value of the difference between the preset state threshold and the ratio corresponding to each of the state data items to obtain the parameters corresponding to each of the state data items, the method further includes: Obtain the maximum threshold parameter corresponding to each preset state data item; Calculate the ratio of the parameter corresponding to each of the state data items to the maximum threshold parameter to obtain the corrected parameter corresponding to each of the state data items.

4. A health monitoring method, characterized in that, The method is applied to a second server, which communicates with multiple first servers, and each first server manages multiple wearable devices; the method includes: The location information, identification information, and health status value of each wearable device uploaded by the first server are obtained, wherein the health status value is obtained by the first server according to the health monitoring method as described in any one of claims 1-3. If the health status value corresponding to the wearable device is within the abnormal threshold range, then the target wearable device and its corresponding first server are determined according to the location information and preset distance threshold of the wearable device, and a help request is sent to the first server corresponding to the target wearable device according to the location information and identification information of the wearable device, so that the help request is sent to the target wearable device through the first server.

5. The health monitoring method according to claim 4, characterized in that, The step of determining the target wearable device and its corresponding first server based on the location information corresponding to the wearable device and a preset distance threshold specifically includes: Wearable devices whose health status values ​​are within the abnormal threshold range are identified as wearable devices requiring assistance. Multiple wearable devices whose health status values ​​are within the normal threshold range are identified as candidate wearable devices; Based on the location information corresponding to the wearable device to be rescued and the location information corresponding to each of the candidate wearable devices, the distance between each of the candidate wearable devices and the wearable device to be rescued is calculated. Candidate wearable devices whose distance is less than the preset distance threshold are identified as target wearable devices, and the first server corresponding to the target wearable device is determined according to the identification information corresponding to the target wearable device.

6. The health monitoring method according to claim 5, characterized in that, After sending a request for help to the first server corresponding to the target wearable device based on the location information and identification information corresponding to the wearable device, the method further includes: If a confirmation help message is received from the first server corresponding to the target wearable device within a first preset time, the location information corresponding to the target wearable device uploaded by the first server corresponding to the target wearable device will be obtained in real time. The target distance is calculated based on the location information corresponding to the target wearable device and the location information corresponding to the wearable device to be rescued; After a second preset time, if the target distance is greater than a preset threshold, a new target wearable device and its corresponding first server are determined based on the distance between each of the candidate wearable devices and the wearable device to be rescued. Based on the location and identification information of the wearable device to be rescued, a request for help is sent to the first server corresponding to the new target wearable device, so that the request for help is sent to the new target wearable device through the first server corresponding to the new target wearable device.

7. The health monitoring method according to claim 6, characterized in that, The method further includes: If no confirmation of rescue is received from the wearable device to be rescued via its corresponding first server within the third preset time, a new target wearable device and its corresponding first server are determined based on the distance between each candidate wearable device and the wearable device to be rescued. Based on the location and identification information of the wearable device to be rescued, a request for help is sent to the first server corresponding to the new target wearable device, so that the request for help is sent to the new target wearable device through the first server corresponding to the new target wearable device.

8. The health monitoring method according to claim 5, characterized in that, After sending a request for help to the first server corresponding to the target wearable device based on the location information and identification information corresponding to the wearable device, the method further includes: If no confirmation help information is received from the target first server within the first preset time, a new target wearable device and its corresponding first server are determined based on the distance between each of the candidate wearable devices and the wearable device to be rescued. Based on the location and identification information of the wearable device to be rescued, a request for help is sent to the first server corresponding to the new target wearable device, so that the request for help is sent to the new target wearable device through the first server corresponding to the new target wearable device.

9. A health monitoring system, characterized in that, The system includes a second server and multiple first servers connected in communication with it, each of the first servers being used to manage multiple wearable devices; The first server is used to obtain the motion mode, current status data group, historical status dataset, location information and identification information uploaded by the wearable device. The historical motion status dataset includes multiple historical status data groups, and multiple status data in the current status data group correspond one-to-one with multiple status data in the historical status data group. The first server is further configured to obtain the historical state data group corresponding to the motion mode from the historical state dataset, calculate the historical average value corresponding to each state data in the historical state data group, calculate the ratio of each state data in the current state data group to its corresponding historical average value, and obtain the ratio corresponding to each state data. The first server is also used to calculate a state health value based on a preset weight and the ratio corresponding to each of the state data, and upload the location information, the identification information and the state health value to the second server; The second server is used to obtain the location information, the identification information, and the status health value corresponding to each of the wearable devices uploaded by the first server; The second server is also used to determine the target wearable device and its corresponding first server based on the location information and preset distance threshold of the wearable device when the health value corresponding to the wearable device is within the abnormal threshold range, and to send a help request to the first server corresponding to the target wearable device based on the location information and identification information of the wearable device. The first server corresponding to the target wearable device is used to send the help request information to the target wearable device.

10. A server, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the health monitoring method according to any one of claims 1 to 3, or the processor executes the computer program to implement the health monitoring method according to any one of claims 4 to 8.

Images