Block chain sharing method and system based on vital sign data health report and storage medium

Abstract

The invention discloses a block chain sharing method and system based on a vital sign data health report and a storage medium. The method comprises the steps of obtaining a vital sign data health report generated by a user in a family environment, storing target medical report data to a data interaction center based on a target unique identifier and a user public key, and newly adding a first transaction record of the user to the data interaction center on a block chain; determining a public key and a block chain address of a target doctor, obtaining a target medical report data format and generation time provided by the target doctor, and adding a second transaction record from the user to the target doctor on a block chain; and encrypting the target unique identifier corresponding to the target medical report data by using the public key of the target doctor, and newly adding a third transaction record from the user to the target doctor on the block chain, thereby solving the technical problem of ensuring the security and privacy of information transmission in the efficient interaction process of the family medical data information.

Description

Technical Field

[0001] The present invention relates to the field of computers, and in particular to a blockchain sharing method, system and storage medium based on vital sign data health reports. Background Art

[0002] The development of the healthcare sector is shifting from hospital-led to home environments. Homes provide a more convenient and faster disease monitoring environment than hospitals, but related applications are not yet mature. Real-time detection of acute diseases and long-term observation of chronic diseases require reliable detection methods and data management protocols that meet medical standards. Traditional medical data management systems are often limited to a single medical institution or network, and data sharing and communication between different institutions are limited, resulting in information islands. This not only affects the continuity and efficiency of medical services, but also limits the comprehensive use of data, such as cross-institutional medical research.

[0003] To sum up, the existing technology has the problem of information islands of home medical data, and the existing technology cannot guarantee the security and privacy of user medical data in the home environment. There is no effective solution to the technical problem of how to ensure the security and privacy of information transmission during the efficient interaction of home medical data information. Summary of the invention

[0004] The embodiments of the present invention provide a blockchain sharing method, system and storage medium based on vital sign data health reports, so as to at least solve the technical problem of ensuring the security and privacy of information transmission during the efficient interaction of family medical data information.

[0005] According to one aspect of an embodiment of the present invention, a blockchain sharing method based on a vital sign data health report is provided, comprising:

[0006] Obtain target medical report data generated by the user in a home environment, store the target medical report data in a data interaction center based on the target unique identifier and the user's public key, and add a first transaction record from the user to the data interaction center on the blockchain, wherein the target unique identifier includes a hash value generated locally by the user;

[0007] Determine the public key and blockchain address of the target doctor, obtain the target medical report data format and generation time provided by the target doctor, and, upon confirming that the user authorizes access to send the report data, add a second transaction record from the user to the target doctor on the blockchain, wherein the second transaction record includes the user authorizing the target doctor to access the target medical report data generated during a specified time period;

[0008] The target unique identifier corresponding to the target medical report data is encrypted using the public key of the target doctor, and a third transaction record from the user to the target doctor is added to the blockchain, wherein the third transaction record includes the encrypted target unique identifier sent by the user.

[0009] According to another aspect of an embodiment of the present invention, a blockchain sharing system based on vital sign data health report is also provided, including:

[0010] A report generation module, used to collect vital sign data from wearable sensors and IoT sensors in a smart and healthy home in a home environment to generate the above-mentioned target medical report data, wherein the above-mentioned report generation module includes a sensor and data gateway module and a smart and healthy home edge analysis module;

[0011] A data interaction module, used for interactive operations between the target medical report data and the blockchain, determining the target unique identifier and user public key, determining the target doctor's public key and blockchain address, and using the public key to encrypt and decrypt the target unique identifier corresponding to the target medical report data;

[0012] A data exchange center, used to store the above target medical report data and the corresponding above target unique identifier;

[0013] The corresponding database of the central server of the medical institution is used to store the above-mentioned final target medical report data;

[0014] Blockchain is used to store target medical report data transmission and access records.

[0015] According to another aspect of an embodiment of the present invention, a blockchain sharing device based on a vital sign data health report is also provided, including:

[0016] An acquisition unit is used to acquire a vital sign data health report generated by a user in a home environment, store target medical report data in the vital sign data health report to a data interaction center based on a target unique identifier and a user public key, and add a first transaction record from the user to the data interaction center on a blockchain, wherein the target unique identifier includes a hash value generated locally by the user;

[0017] a determination unit, configured to determine a public key and a blockchain address of a target doctor, obtain a target medical report data format and a generation time provided by the target doctor, and, upon confirming that the user authorizes access to send the report data, add a second transaction record from the user to the target doctor on the blockchain, wherein the second transaction record includes the user authorizing the target doctor to access the target medical report data generated during a specified time period;

[0018] The encryption unit is used to encrypt the target unique identifier corresponding to the target medical report data using the public key of the target doctor, and add a third transaction record from the user to the target doctor on the blockchain, wherein the third transaction record includes the encrypted target unique identifier sent by the user.

[0019] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the above-mentioned blockchain sharing method based on vital sign data health report when running.

[0020] According to another aspect of an embodiment of the present invention, an electronic device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the blockchain sharing method based on vital sign data health report through the computer program.

[0021] In an embodiment of the present invention, a vital sign data health report generated by a user in a home environment is obtained, and the target medical report data in the vital sign data health report is stored in a data interaction center based on the target unique identifier and the user public key, and a first transaction record from the user to the data interaction center is added on the blockchain, wherein the target unique identifier includes a hash value generated locally by the user; the public key and blockchain address of the target doctor are determined, and the target medical report data format and generation time provided by the target doctor are obtained. When confirming that the user authorizes access to send the report data, a second transaction record from the user to the target doctor is added on the blockchain, and the second transaction record includes the user's authorization The target doctor is authorized to access the target medical report data generated in the specified time period; the target unique identifier corresponding to the target medical report data is encrypted using the public key of the target doctor, and a third transaction record from the user to the target doctor is added to the blockchain. The third transaction record includes the encrypted target unique identifier sent by the user, thereby achieving the purpose of interaction between the user in the family and the doctors and other medical workers in the medical institutions. The interaction process can solve the problem of information islands based on the blockchain, and the interaction process is safe and reliable, avoiding the interaction of sensitive data, and solving the technical problem of ensuring the security and privacy of information transmission during the efficient interaction of family medical data information. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0023] Figure 1is a schematic diagram of a flow chart of an optional blockchain sharing method based on vital sign data health report according to an embodiment of the present invention;

[0024] Figure 2 is a schematic diagram of a flow chart of an optional blockchain sharing method based on vital sign data health report according to an embodiment of the present invention;

[0025] Figure 3 is a schematic diagram of a flow chart of an optional blockchain sharing method based on vital sign data health report according to an embodiment of the present invention;

[0026] Figure 4 is a schematic diagram of another optional blockchain sharing method based on vital sign data health report according to an embodiment of the present invention;

[0027] Figure 5 is a schematic diagram of another optional blockchain sharing method based on vital sign data health report according to an embodiment of the present invention;

[0028] Figure 6 is a schematic diagram of another optional blockchain sharing method based on vital sign data health report according to an embodiment of the present invention;

[0029] Figure 7 is a schematic diagram of another optional blockchain sharing system based on vital sign data health report according to an embodiment of the present invention;

[0030] Figure 8 is a schematic diagram of an optional blockchain sharing device based on vital sign data health report according to an embodiment of the present invention;

[0031] Fig. 9 is a schematic structural diagram of an optional electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0032] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0033] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0034] The development of the healthcare sector is shifting from hospital-led to home environments. Homes provide a more convenient and faster disease monitoring environment than hospitals, but related applications are not yet mature. Real-time detection of acute diseases and long-term observation of chronic diseases require reliable detection methods and data management protocols that meet medical standards. Traditional medical data management systems are often limited to a single medical institution or network, and data sharing and communication between different institutions are limited, resulting in information islands. This not only affects the continuity and efficiency of medical services, but also limits the comprehensive use of data, such as cross-institutional medical research.

[0035] Blockchain technology provides a decentralized data management framework, which provides data immutability, high transparency and traceability with continuous block data structure and distributed ledger technology. Data updates need to be verified by multiple nodes and stored in encrypted form. Through smart contracts, only authorized users and entities can access sensitive data. Verification of data integrity and traceability reduces the risk of misdiagnosis caused by erroneous data. These features protect data security and privacy, and provide guarantees for the sharing and use of medical and health data in home environments.

[0036] This embodiment combines blockchain technology, and realizes the sharing of anonymous data and health reports through the measurement of family vital signs data and the generation of related health reports and blockchain technology. The data and reports do not contain the user's identity information. Doctors authorized by smart contracts can associate the user's identity information. Unauthorized doctors can access the data exchange center to obtain data and reports that are allowed to be shared, but cannot locate the user who shared the data and reports. At the same time, this embodiment defines the content of family vital signs data measurement and related health reports, filling the gap in the direction of family development in the health field.

[0037] Optionally, as an optional implementation, as Figure 1 As shown, the blockchain sharing method based on vital signs data health report includes:

[0038] S102, obtaining a vital sign data health report generated by the user in a home environment, storing the target medical report data in the vital sign data health report to a data interaction center based on the target unique identifier and the user's public key, and adding a first transaction record from the user to the data interaction center on the blockchain, wherein the target unique identifier includes a hash value generated locally by the user;

[0039] S104, determining the public key and blockchain address of the target doctor, obtaining the target medical report data format and generation time provided by the target doctor, and adding a second transaction record from the user to the target doctor on the blockchain when confirming that the user authorizes access to send the report data, the second transaction record includes the user authorizing the designated target doctor to access the target medical report data generated during the specified time period;

[0040] S106, using the public key of the target doctor to encrypt the target unique identifier corresponding to the target medical report data, and adding a third transaction record from the user to the target doctor on the blockchain, the third transaction record includes the encrypted target unique identifier sent by the user.

[0041] Optionally, in this embodiment, the executor of the above-mentioned blockchain sharing process based on vital sign data health report is a data interaction module, and the specific control method includes the data interaction module acquiring the target medical report data generated by the user in the home environment, storing the target medical report data in the data interaction center based on the target unique identifier and the user's public key, and adding the first transaction record of the user to the data interaction center on the blockchain; after the user selects the target doctor, the data interaction module confirms the public key and blockchain address of the target doctor, and the target doctor also provides the target medical report data format and generation time to the data interaction module, and when confirming that the user authorizes access to send the report data, the user is added to the blockchain. The second transaction record of the target doctor; the target unique identifier corresponding to the target medical report data is encrypted using the public key of the target doctor, and a third transaction record from the user to the target doctor is added on the blockchain. The third transaction record includes the encrypted target unique identifier sent by the user. The above interaction process and transaction record achieve the purpose of interaction between users in the family and doctors and other medical workers in medical institutions. The interaction process can solve the problem of information islands based on blockchain, and the interaction process is safe and reliable, avoiding the interaction of sensitive data. The transaction record ensures the integrity of the interaction process and prevents data loss, thereby achieving the security and privacy of information transmission while ensuring the efficient interaction of family medical data information.

[0042] Optionally, as an optional implementation method, the target medical report data can be displayed in the form of an anonymous report. After the third transaction record from the user to the target doctor is added on the blockchain, when the target doctor needs to view the target medical report data, the encrypted target unique identifier is decrypted using the target doctor's private key, and the target medical report data corresponding to the target unique identifier is downloaded from the data exchange center; when the target doctor determines to accept the target medical report data, the final target medical report data is stored in the database corresponding to the user in the central server of the medical institution, and a fourth transaction record from the target doctor to the user is added on the blockchain.

[0043] As an optional embodiment, for example Figure 2 As shown, the data interaction module obtains the target medical report data generated by the user in the home environment, stores the target medical report data in the data interaction center based on the target unique identifier and the user's public key, and adds the first transaction record from the user to the data interaction center on the blockchain; after the user selects the target doctor, the data interaction module confirms the target doctor's public key and blockchain address, and the target doctor also provides the data interaction module with the target medical report data format and generation time. When confirming that the user authorizes access to send the report data, a second transaction record from the user to the target doctor is added on the blockchain; the target unique identifier corresponding to the target medical report data is encrypted using the target doctor's public key, and the user is added to the target doctor on the blockchain The third transaction record; after the third transaction record from the user to the target doctor is added on the blockchain, when the target doctor needs to view the target medical report data, the encrypted target unique identifier is decrypted using the target doctor's private key, and the target medical report data corresponding to the target unique identifier is downloaded from the data exchange center; after the target doctor obtains the anonymous target medical report data, the hash value is sent to the user. After the user verifies the hash value, the user sends a reception request or a rejection request to the target doctor. When the target doctor determines to accept the target medical report data, the final target medical report data is stored in the database corresponding to the user in the central server of the medical institution, and a fourth transaction record from the target doctor to the user is added on the blockchain.

[0044] Optionally, in this embodiment, the data interaction module may, but is not limited to, generate a public key and a private key pair as the user's account information through the data interaction module before acquiring the target medical report data generated by the user in the home environment. In blockchain technology, a public key and a private key pair is a key pair obtained through an asymmetric encryption algorithm, including a public key and a private key. The public key is generally disclosed to the outside world, and the private key is generally retained by oneself. The public key is usually used to encrypt data, verify digital signatures, etc., and the private key is generally used to decrypt data and generate digital signatures. When using this key pair, if the public key is used for encryption, another corresponding private key must be used for decryption. The integrity and security of the transaction can be ensured by setting the public key and private key pair. Methods for generating public and private key pairs include but are not limited to elliptic curve encryption, ED25519, and RSA encryption, and the signature algorithm includes but is not limited to digital signature algorithm and ElGamal. According to the selected blockchain, the blockchain address is generated by the user's public key.

[0045] As an optional embodiment, the process of obtaining the target medical report data generated by the user in the home environment calls the sensor and data gateway module, and the smart health home edge analysis module generates the target medical report data. The target medical report data does not contain personal identity data, but uses an anonymous target unique identifier as the report number, and the user's public key as the generator identifier. The user generates the report hash value locally.

[0046] As an optional embodiment, the target unique identifier is generated by, but not limited to, using a timestamp, a user public key, randomness, a report hash value, a device identifier, such as a device's MAC address or UUID, a report type, and other elements to obtain a concatenated string, which can be separated by a specific separator, such as "-".

[0047] As an optional embodiment, when a concatenated string is obtained, a plurality of hash algorithms are used to perform hash calculation on the concatenated string to generate a unique identifier, wherein the hash algorithms used include but are not limited to SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, MD5, Blake2, etc. The target medical report data is stored in the data exchange center based on the generated unique identifier and the user public key. After uploading to the data exchange center, the unique identifier corresponding to the target medical report data is detected. If it is detected that the unique identifier corresponding to the target medical report data is repeated with other unique identifiers when uploading to the data exchange center, first verify whether the local medical report data has been uploaded. If the content of the medical report data is different, modify the random number and regenerate the unique identifier until a unique identifier is generated, and then determine the unique identifier as the target unique identifier.

[0048] As an optional embodiment, when a concatenated string is obtained, a hash calculation is performed on the concatenated string using a hash algorithm to generate a first unique identifier. The first unique identifier can be understood as a unique identifier that has not yet been detected and determined to be stored in a data exchange center. It is detected whether the first unique identifier is repeated with other unique identifiers stored in the data exchange center. If there is a duplication in the first unique identifier, the random number is modified and the first unique identifier is regenerated. The detection step is repeated until there is no duplication in the first unique identifier. If there is no duplication in the first unique identifier, the first unique identifier is determined as the target unique identifier.

[0049] As an optional embodiment, the data interaction module sends the report data to the data exchange center and stores it in the database of the data exchange center. When the user sets the sharing authorization to allow, the report allows any doctor and medical institution with access to the data center to access and download. When the user sets it to prohibit, only authorized doctors are allowed to access and download the report. The data exchange center generates a report hash value and compares it with the user's local hash value to confirm the first transaction record of the newly added user to the data exchange center on the chain. The first transaction record includes but is not limited to the target unique identifier, user public key, data exchange center public key, and sharing authorization allowed;

[0050] As an optional embodiment, the user selects a target doctor through the data interaction module. The target doctor can be a doctor in a medical institution selected by the user, or a department corresponding to a potential disease evaluated by the smart health home edge analysis module, matching the hospital department code, such as the "List of Diagnosis and Treatment Subjects of Medical Institutions", the common medical procedure code CPT Code, etc., and then listing the target doctors for the consultation. The above-mentioned target doctors are pseudonyms, including medical workers with different divisions of labor, such as doctors, nurses, pharmacists, medical laboratory technicians, psychologists, social workers, nutritionists and other personnel who are qualified to provide medical diagnosis advice.

[0051] As an optional embodiment, the data interaction module obtains the doctor's public key and the doctor's blockchain address. The doctor provides the format of the report to be accessed as the target medical report data format and the generation date time period. The format of the report data can be a default template, or a report describing a specific disease, or a report format set in cooperation with a medical institution. The user's data interaction module and the smart health home edge analysis module use a dynamic code binding verification scheme to confirm the user's authorization to access the report sending operation, such as time synchronization one-time password, event synchronization one-time password, SMS / email verification code biometric verification combined with dynamic code, public and private key pair generation signature code, dynamic QR code generation, etc. When the user sends the report, the data interaction module generates a first dynamic code. The user enters the first dynamic code and matches it with the second dynamic code on the smart health home edge analysis module side to authorize access and send the local report. The second transaction record of the user-doctor smart contract is added to the chain, and the content is the user's authorization to specify the target doctor to access the report data generated in the specified time period;

[0052] As an optional embodiment, the user submits the target medical report data through a data interaction terminal, which can be a user's smartphone, tablet computer or computer equipped with a specific application or web interface for collecting and processing report data. The user generates a pair of public and private keys for encrypting and decrypting data. The user encrypts the target unique identifier of the anonymous target medical report data using the doctor's public key. The target unique identifier can be a hash value or other unique identifier of the report, and the target unique identifier is a unique string used to identify the report without duplication with other reports.

[0053] As an optional embodiment, the data interaction module uses the doctor's public key to encrypt the unique identifier to ensure that only the target doctor can decrypt and view the identifier. The blockchain smart contract is used to add a third transaction record in which the user sends the encrypted identifier to the doctor. The smart contract contains encrypted information, that is, the encrypted report data unique identifier, and other necessary metadata, such as timestamp, report type, etc. The smart contract sends this information to the blockchain network to generate an unalterable transaction record. The target doctor obtains the third transaction record from the blockchain network. Use the doctor's private key to decrypt the encrypted target unique identifier to confirm the authenticity and source of the target medical report data.

[0054] As an optional embodiment, the target doctor uses a private key to decrypt the information sent by the user through the data interaction module, obtains the decrypted target unique identifier, and downloads the target medical report data corresponding to the target unique identifier from the data exchange center. The target medical report data stored in the database of the data exchange center uses the anonymous target unique identifier as an index. The target medical report data itself does not contain the target unique identifier that can correspond to the user. When the doctor needs to understand the report of the corresponding person, it is necessary to determine the report of the corresponding person by comparing the hash value. When the doctor needs to view the target medical report data, the doctor uses the private key to decrypt the encrypted target unique identifier sent by the user through the data interaction module. After decryption, the doctor obtains the unique identifier of the report, that is, the hash value, and uses the target unique identifier to download the corresponding target medical report data from the database of the data exchange center. The target medical report data in the database uses the target unique identifier including the hash value as an index. The doctor compares the hash value to ensure that the downloaded target medical report data is consistent with the target medical report data submitted by the user, thereby ensuring the uniqueness and accuracy of the target medical report data and the privacy of the user.

[0055] As an optional embodiment, the doctor generates a hash value of the target medical report data locally through the data interaction module and sends it to the user. The user compares the hash value with the locally generated hash value. If the hash values ​​are consistent, it is confirmed that the report received by the doctor is correct, that is, the target doctor decides to accept the target medical report data. If they are inconsistent, the report is rejected, that is, the target doctor refuses to accept the target medical report data and reselects the report or exits.

[0056] As an optional embodiment, the method for determining the accuracy of the report is specifically that the doctor generates a hash value for the received report content through the data interaction module, for example, a hash value generated using the SHA-256 algorithm, and the generated hash value is sent to the user through the data interaction module. The user compares the hash value sent by the doctor with the locally generated report hash value. If the two hash values ​​are consistent, it means that the report content has not been tampered with, confirming that the report received by the doctor is correct. If the hash values ​​are inconsistent, the user rejects the report and is prompted to reselect the report or exit.

[0057] The application scenario of the above embodiment is to prevent upload errors. During the report transmission process, errors may occur in the report data due to network problems, duplicate identifiers or other reasons. By comparing the hash values, users can ensure that the report received by the doctor is consistent with the report they submitted, preventing upload errors from affecting the diagnosis results.

[0058] The application scenario of the above embodiment is to prevent data confusion. During the report processing and storage process, data confusion or confusion may occur due to system failure or human operation. Hash value comparison can effectively detect and prevent data confusion and ensure the integrity and accuracy of report data.

[0059] The application scenario of the above embodiment is data tampering detection, that is, by comparing the decrypted data on the blockchain, the user's local data, the data of the data exchange center and the latest modification timestamp, it can be determined whether the report data has been tampered with in the storage, and the data of the three parties that are different and modified later can be considered to have been modified.

[0060] The application scenario of the above embodiment is to confirm the integrity of the report. The hash value comparison ensures that the report content is not modified or lost during the transmission process, thereby ensuring the integrity of the data. It is suitable for medical scenarios that require high data integrity and security.

[0061] The doctor stores the final target medical report data verified by the hash value in the user's health report on the central server of the medical institution, and adds the fourth transaction record of the target doctor to the user through the blockchain smart contract, confirming that the final target medical report data has been stored in the medical institution database. Optionally, the doctor's diagnosis information of this visit can be used as a supplement to the target medical report data to the final target medical report data. For the target medical report data that allows shared authorization in the health report of the data exchange center, if the doctor and the medical institution need to apply for access to other target medical report data of the same user, they can send a request to the data exchange center as the applicant, and the data exchange center forwards the request to the user. After the user agrees, the access authorization for the applicant is added to the blockchain, and the applicant can download the health report list from the data exchange center. The health report list can include but is not limited to all the medical report data of the user. The authorization of the health report list facilitates the target doctor to understand the user's historical health information and improves the efficiency of diagnosis.

[0062] As an optional embodiment, for example Figure 3 As shown, the user logs in to the personal account to generate the target medical report data. After the user selects the target doctor, the authorization information is sent through the blockchain; the user sends the encrypted target unique identifier to the doctor through the blockchain; the target doctor decrypts the target unique identifier and downloads the target medical report data from the data exchange center; the target doctor and the user verify the integrity and security of the report; the target doctor stores the final target medical report data in the central database of the medical institution, and after obtaining permission, requests more target medical report data from the user.

[0063] Optionally, as an optional implementation, obtaining target medical report data generated by the user in a home environment in a report generation unit also includes: obtaining first signal data in multiple formats through wearable sensors and Internet of Things sensors in a smart health home; performing data preprocessing and verification on the first signal data to determine second signal data; and converting the second signal data into unified standard format data.

[0064] Optionally, as an optional implementation, the target medical report data is classified and disease risk is predicted, including: extracting features of the target medical report data; inputting various features of the target medical report data into a trained classification model, wherein the classification model classifies the target medical report data into possible diseases; inputting various features of the target medical report data into a trained prediction model, wherein the prediction model determines the average distance between the user's current health status and the disease boundary based on historical health data features and current data features, and generates health advice; and displaying the results obtained by the classification model and the prediction model on the terminals of the user and the target doctor through a visual interface.

[0065] Optionally, as an optional implementation, the newly added part of report generation may include, but is not limited to, a process of fusing, analyzing and reporting data measured by multiple sensors, such as Figure 4 The generation of a sleep health report is shown as an optional implementation. Through wearable sensors and IoT sensors in smart healthy homes, the original signals of measurements such as ECG signals, photoelectric volume pulse, acceleration, sound, body temperature and environmental parameters can be obtained. These measured original signals will be preprocessed and verified, including data smoothing, data cleaning, noise removal, outlier removal, signal standardization, time alignment, feature extraction and selection, and ensure data consistency and availability. The verified data is further refined into heart rate data, blood oxygen saturation data, activity data, noise data, snoring data, body temperature data and indoor environment data, such as light, indoor temperature, indoor humidity, air pressure and air quality.

[0066] Noise removal is the first step to remove noise from the data collected by the sensor. The system will first use a variety of commonly used filters in combination: low-pass filter, mainly used to remove high-frequency noise, used to remove high-frequency interference caused by movement; high-pass filter: used to eliminate low-frequency drift, such as baseline drift, used to remove baseline fluctuations caused by breathing in ECG signals; bandpass filter, combining low-pass and high-pass filters, only allows signals in a specific frequency band to pass through to retain the main components of the signal while removing noise; notch filter, specifically used to eliminate fixed-frequency interference, such as power line interference; moving average filter, smoothes the signal by calculating the average value of the signal window, used to reduce random noise. After completing the preliminary filtering, the system will use wavelet transform to remove non-periodic and transient noise and process nonlinear or non-stationary signals; adaptive filters can also be used to automatically adjust their parameters according to the real-time characteristics of the signal, which is implemented using the least mean square algorithm or recursive least squares algorithm.

[0067] Outlier processing is the process of finding and marking outliers, or so-called outliers, after noise removal to ensure the accuracy of analysis and diagnosis. The system will preferentially use the following methods to detect and mark outliers: Threshold method, which sets thresholds based on experience or statistical analysis. Any point exceeding these thresholds is considered abnormal. For example, a normal range of heart rate is set, such as a heart rate below 40 beats per minute or above 180 beats per minute is considered abnormal; Standard deviation method, data points that differ from the mean by more than a certain multiple of the standard deviation are considered abnormal; Interquartile range method, which calculates the quartiles (Q1, Q3) and interquartile range (IQR = Q3-Q1) of the data, and then finds data points that exceed Q1-1.5*IQR or Q3+1.5*IQR. If the signal quality is complex or the source is special, such as from patients with certain diseases, whose signal characteristics will be different from those of the general population, the system will use the sliding window local anomaly factor method to analyze the local density deviation of each point and its neighboring points in the sliding window. Points with local density significantly lower than that of their neighbors are considered to be abnormal points; or use the signal quality index to evaluate the quality of the signal segment. Low-quality signal segments will be marked as containing more outliers or noise.

[0068] Time alignment is when processing multiple sensor data, different sensors have different sampling frequencies and there may be timestamp offsets, the system will perform timestamp alignment operations. The time alignment methods used include but are not limited to resampling. When the sampling frequencies of sensors are inconsistent, the system resamples all sensor data to a common sampling frequency, including upsampling and downsampling; timestamp correction. For the case of timestamp offset, the system will first determine the size of the time deviation. The principle can be achieved by analyzing the occurrence time of known events in the signal, or using a synchronization signal. After determining the time offset, the system will use the cross-correlation method to align the data from different sensors. It calculates the cross-correlation of two signals to find the time offset, so as to maximize the correlation of the signals.

[0069] Data smoothing is the process of smoothing the data after time alignment to reduce random errors or noise while retaining useful signal trends. The system will give priority to using the moving average or weighted moving average method to smooth the data by calculating the average value of the data window. The window size, that is, N seconds, can be adjusted as needed. If N=10 is selected, each data point will be the average of the heart rate data for the previous 10 seconds; but when adding weights, different data points will be given different weights by the system. Usually, more recent data points have higher weights, which can give more attention to recent changes, so that the smoothed data can better reflect recent changes.

[0070] For example, when obtaining heart rate data from an electrocardiogram, the R wave is first detected from the ECG signal, and the intervals between two consecutive R waves are calculated, which are usually in seconds. The heart rate calculation formula is HR = (60 / RR interval in seconds), which can give the number of heart beats per minute. For smoothing, different N values ​​can be selected for moving average processing. If N is set to 5 seconds, the smoothed current heart rate will be the average of the heart rates per second in the previous 5 seconds. This method can reduce the fluctuations in heart rate data caused by natural fluctuations in heart beat intervals or measurement errors, making the resulting heart rate curve smoother and more suitable for trend analysis or further physiological status assessment.

[0071] Signal standardization is the process of converting data from different sources or different scales into a unified standard format for comparison, analysis or subsequent algorithm processing, because different measurement equipment, methods or objects may cause data to differ in dimension or magnitude. The system will preferentially use the minimum-maximum standardization to scale the original data so that all data points are evenly distributed within a specified range, usually 0 to 1. The basic formula is: X = (X-Min(X) / Max(X)-Min(X)). However, it is susceptible to outliers, which may cause most data to be compressed in a very small range. Therefore, when there are many outliers, the system will use the Z-score standardization method to convert the data by adjusting the mean of the data to 0 and the standard deviation to 1. The basic formula is: Z = (X-mean of the original data) / standard deviation of the original data.

[0072] Feature extraction, including applying multiple machine learning models, such as sleep apnea machine learning models, features extracted from density maps or features extracted from time series analysis, will be used for training and use of machine learning models. The training of machine learning models requires about 3 features to about 30 features.

[0073] In this embodiment, there are 22 features, including 15 features of density map and 7 features of time series analysis, wherein the density map feature uses density window analysis to extract and analyze the features of continuous time series heart rate data.

[0074] The parameters obtained by density window analysis and time series analysis, and the parameters obtained by processing blood oxygen saturation, activity, snoring and environmental data using time series analysis, are input into the sleep apnea machine learning detection model. The system uses the extracted feature parameters and classification algorithms such as support vector machines, random forests, and multi-layer perceptrons to classify and predict sleep apnea, and improves the accuracy and robustness of the model through cross-validation and hyperparameter optimization. The system can comprehensively evaluate the situation of sleep apnea, including the presence and severity of sleep apnea in different time windows.

[0075] In order to further improve the accuracy and robustness of the model, the system introduces cross-validation and hyperparameter optimization techniques. Cross-validation is a process in which the system divides the data into multiple training sets and validation sets, repeatedly trains and validates the model, ensures the generalization ability of the model, and prevents overfitting. Hyperparameter optimization is a process in which the system uses grid search or Bayesian optimization and other techniques to automatically adjust the model's hyperparameters to find the optimal model configuration.

[0076] Sleep stage analysis combines heart rate data, blood oxygen saturation data, and activity data and inputs them into the sleep stage machine learning classification model. Similar to the above, classification algorithms such as support vector machine, random forest, and multi-layer perceptron are used to obtain statistical results of sleep stages, including the duration of deep sleep, light sleep, and REM sleep stages and their transition frequency.

[0077] Activity data is used to analyze and count activity intensity and sleeping posture, blood oxygen saturation data is used to generate blood oxygen saturation statistics, and noise data and snoring data are used to evaluate the frequency and intensity of snoring. In addition, noise data, body temperature data, light, indoor temperature, indoor humidity, air pressure, and air quality data are used to generate statistics of other health-related parameters.

[0078] Eventually, sleep apnea assessment, sleep stage statistics, activity and posture statistics, blood oxygen saturation statistics, snoring statistics, and other health-related parameter statistics will be integrated through an aggregator based on rules and corresponding medical report standard templates. The rule engine evaluates various health parameters based on medical standard templates and predefined rules to generate personalized health analysis results. The system defines several rules based on the relationship between different parameters. For example, when the frequency of sleep apnea is higher than a certain threshold, the system will generate a "high risk" prompt and further evaluate it in combination with other parameters, such as the frequency and amplitude of decreased blood oxygen saturation. According to the requirements of clinical medicine, the system pre-sets a variety of standard templates for health reports. The definition of the template takes into account the clinical reference values, normal ranges, abnormal indications of different parameters, and how to generate health recommendations and risk assessments based on these indicators.

[0079] As an optional embodiment, the method for generating health report data is as follows: Figure 5 As shown, it includes a sensor and data gateway module S100 and a smart healthy home edge analysis module S200. The method aims to provide personalized and accurate health monitoring and reporting services for families.

[0080] The sensor and data gateway module S100 includes a sensor measurement module S110 and a data collection module S120.

[0081] The sensor measurement module S110 includes a variety of different types of sensors, which can be wearable devices, IoT devices or other medical devices and measurements, including but not limited to: Personal health-related measurements S111 use the protocols required by medical standards to perform health-related measurements with timestamps, which measure the patient's biological body, and the collected data include but are not limited to vital signs, health observations and physical characteristics. Measurement of fitness-related parameters S112 records fitness parameters from sports equipment, including but not limited to activity type, intensity, exercise plan and goals, energy consumption. Measurement of environmental conditions S113 performs measurements of environmental conditions with timestamps, covering the measurement period related to health, including but not limited to air temperature, air humidity, atmospheric pressure, air quality indicators, noise level, light intensity, mechanical vibration, and the presence of other humans or animals. Nutrition-related measurements S114 record the nutritional components of meals with timestamps, which are used to observe the patient's measurement period, covering the content, quantity, nutritional characteristics, etc. of meals related to health. Other health-related measurements S115 perform other health-related measurements related to the patient group, including but not limited to falls, sweating, snoring, etc.

[0082] The data collection module S120 includes a personal data terminal S121 and a smart home gateway S122. The health data collected through personal health-related measurements S111 and fitness-related parameter measurements S112 are transmitted to the registered and bound personal data terminal S121 through wireless transmission, such as Bluetooth or wireless LAN. The personal data terminal can pre-process, verify and filter the data to ensure the accuracy and completeness of the data. The health data collected through fitness-related parameter measurements S112, nutrition-related measurements S114 and other health-related measurements S115, as well as the health data collected through the personal data terminal S121 are transmitted to the registered and bound smart home gateway S122 through wireless transmission, such as Bluetooth or wireless LAN. Then, the data is transmitted to the smart healthy home edge analysis module S200 through a secure communication method.

[0083] The smart healthy home edge analysis module S200 includes a data analysis module S210 and an anonymous health report module S220. The data analysis module S210 uses advanced algorithms to monitor, analyze and predict diseases of users' health data for a long time. The analysis terminal can use machine learning and other technologies to deeply process the data to discover potential health problems or trends, including but not limited to sleep apnea analysis S211, arrhythmia analysis S212, hypertension analysis S213, etc. The analysis method is shown in the data analysis step example S210-0. The edge analysis module will first perform data verification S210-1 on the collected data, including the source of the data, the integrity and consistency of the data, etc. Then, the edge analysis module will perform data cleaning S210-2 operations, including processing outliers and missing values, etc. Next, the data processing S210-3 module will process the intercom data and convert it into the target form that needs to be analyzed, depending on the required data analysis situation. The processed data will be feature extracted by the feature analysis module S210-4. The extracted features are used to obtain analysis results S210-6 through a machine learning model S210-5-1 or a statistical model S210-5-2.

[0084] The anonymous health report module S220 protects the user's privacy by generating anonymous health reports. The module can generate various types of health reports based on the analysis results, which can be used by doctors for medical decision-making or the user's own health management. The anonymous health report module S220 can generate different types of health reports to meet the diverse needs of users. The anonymous health report module S220 can generate various types of health reports such as Figure 6 As shown, for example, sleep apnea monitoring report S221, arrhythmia detection report S222 and blood pressure monitoring report S223, so as to comprehensively cover the user's health status. The sleep apnea monitoring report S221 and blood pressure monitoring report S222 are used as examples below. Sleep apnea monitoring report S221: The report may include but is not limited to the following: report unique identification code, report timestamp, anonymous user code, smart home code, device identification code, sleep duration, sleep time / wake-up time, sleep apnea assessment, heart rate trend during sleep, blood oxygen saturation trend during sleep, activity trend during sleep, noise and snoring trend during sleep, and health care recommendations. Blood pressure monitoring report S222: The report may include but is not limited to the following: report unique identification code, report timestamp, anonymous user code, smart home code, device identification code, hypertension assessment results, cardiovascular risk prediction, blood pressure trend analysis, and health care recommendations.

[0085] As an optional embodiment, for example Figure 6The figure shows a sleep health report format. These analysis results include the assessment of the severity of sleep apnea, the trend of heart rate changes, the frequency and amplitude of the decrease in blood oxygen saturation, the changes in activity intensity and sleeping posture, the assessment of snoring, and the impact of environmental factors on sleep quality. The report consists of three main parts, including the title area, the summary area, and the evaluation area. The title area contains the time when the report was generated and the unique report ID. The basic information of the user is marked, including the user ID, healthy family ID, user type, gender, weight and age; the summary area summarizes the main information of the report, such as the assessment results of sleep apnea, the assessment results of hypertension, etc., and provides recommended medical reference ranges and explanations. The evaluation area is used to conduct a detailed health assessment of the report.

[0086] Sleep apnea assessment includes detailed sleep time statistics, such as the time to fall asleep / wake up, sleep duration, frequency and severity of sleep apnea events, and snoring statistics, such as snoring volume and duration. Heart rate statistics include the average, maximum and minimum heart rate during sleep. Blood oxygen saturation statistics include a detailed display of the average, minimum and duration percentage of blood oxygen saturation below a specific threshold during sleep. Sleep stages include the distribution of each stage in the sleep cycle, including deep sleep, light sleep, REM sleep, etc. Other health-related parameters include the impact of environmental factors on sleep, such as noise level, indoor temperature, humidity, etc.

[0087] After the report is generated, the system will generate corresponding health recommendations based on the analysis results. These recommendations may include recommendations to improve the sleeping environment, such as reducing noise, adjusting the temperature, lifestyle adjustments such as increasing exercise, proper diet, and reminders of the need for further medical examinations or treatments, such as recommendations for medical treatment for severe sleep apnea.

[0088] At the same time, the system uses the trained model to classify new health reports and predict disease risks. Classification includes categorizing the health characteristics involved in the report into disease categories, and prediction includes the assessment of future health risks, such as predicting the possible time of disease occurrence and severity.

[0089] Health report classification includes model building and classification tasks.

[0090] Model building includes but is not limited to the system extracting key features from reports, including results obtained through machine learning disease detection models, such as sleep apnea scores, arrhythmia scores, etc., and results obtained through statistical analysis, such as the lowest value of blood oxygen saturation, standard deviation of activity intensity, etc. These features are input into the classification model as input data. During the model training phase, the system uses annotated data provided by doctors or professionals. The annotated data includes the correspondence between the features extracted from each report and the actual disease diagnosis results. These annotated data are used to train the classification model so that the model can learn to identify the relationship between different features and disease categories.

[0091] When training the classification model, the system uses a variety of classification algorithms to train the classification model, including but not limited to support vector machines, random forests, gradients, Gaussian processes, and multi-layer perceptrons. These algorithms have their own advantages and can handle different types of data and classification tasks. In order to improve the generalization ability of the model, the system uses cross-validation technology to divide the data into multiple training sets and validation sets, and repeatedly train and validate. In addition, the system automatically adjusts the parameters of the model through hyperparameter optimization to find the best configuration.

[0092] The classification task includes but is not limited to when the system receives a new health report, first inputting the various features in the report into the trained classification model. The model classifies the conditions in the health report into possible diseases based on the input features. For example, the system may classify certain features in the report as "sleep apnea", "irregular heartbeat" or other potential diseases. After completing the classification, the system matches the classification results with the ICD-10 codes in the disease database to generate standardized disease codes for the report.

[0093] Disease risk prediction includes model building, health trend analysis and risk prediction.

[0094] Model construction includes but is not limited to the system collecting a large number of health data and disease data samples annotated by doctors. These samples include health characteristics and diagnostic results related to specific diseases, such as the severity of sleep apnea, the type of arrhythmia, etc. Then, the system defines a multidimensional feature space based on the collected data. Each dimension corresponds to a health feature, such as the average heart rate, the minimum blood oxygen saturation, the standard deviation of activity intensity, etc. Each point in the feature space represents the health status of a user. The system builds a health / disease range distribution model by learning health and disease data samples. The model describes the distribution of different health states in the feature space, including the normal range, the abnormal range, and the specific distribution areas of various diseases. When measuring distance, the system introduces a variety of distance measurement methods, such as Euclidean distance, Mahalanobis distance, etc., to calculate the distance between the user's current health state and the health / disease range distribution. For example, the system can calculate the distance between the user's current health state and the boundary of a disease to assess its health risk.

[0095] Health trend analysis and risk prediction include but are not limited to the system generating a user's historical health profile by regularly monitoring and recording the user's health data. Historical data includes past health assessment results, test indicators, and health trend reports automatically generated by the system. When making risk predictions, the system first compares the user's current assessment results with historical records. The system focuses on the average distance between the current assessment value and the abnormal boundary, and the changing trend of this distance in historical data. The system calculates the average distance between the user's current health status and the disease boundary. This distance is the average of the distances in multiple dimensions in the feature space, reflecting the user's overall health status and the risk of disease occurrence. For example, the system can calculate the average distance between the user's current heart rate, blood oxygen saturation, activity intensity and other indicators and the sleep apnea boundary. The system compares the current distance with the historical distance to observe the trend of health conditions. If the distance is significantly shortened, the system will prompt an increase in health risks. The prediction results will be converted into easy-to-understand risk levels, such as low risk, medium risk, high risk, etc. Based on the prediction results, the system automatically generates corresponding health suggestions to help users take preventive measures as soon as possible.

[0096] The system presents the risk prediction results to users and medical professionals through a visual interface. Based on the risk prediction results, the system automatically generates personalized health recommendations. For example, if a user has a higher risk of cardiovascular disease in the next 6 months, the system will recommend regular monitoring, maintaining a healthy diet, and increasing exercise frequency. For high-risk users, the system will prompt the user to seek medical treatment in a timely manner and provide medical information related to the disease.

[0097] As an optional embodiment, for example Figure 7As shown, a blockchain sharing system based on vital sign data health report is proposed, including: report generation module, smart health home database, data interaction module, blockchain, medical institution database, and data exchange center;

[0098] A report generation module, which includes a sensor and data gateway module and a smart health home edge analysis module, and is used to collect and extract vital sign data measured by medical devices and wearable devices in a home environment, and generate medical-grade target medical report data and a target unique identifier based on the target medical report data. The target medical report data does not contain personal identity information, and the target unique identifier is used as an index;

[0099] Smart healthy home database, used for users to store reports and measurement data generated by the report generation module in the home environment, and realize local backup for users;

[0100] The data interaction module is used to operate data and blockchain. This module has identity authentication, permission control, encryption and decryption control, and data verification functions to verify the identity of the user, encrypt and decrypt the information to be transmitted, and verify the integrity and authenticity of the information sent and received, and whether there is tampering, addition or deletion;

[0101] Blockchain is used to share family vital sign data measurements and related health reports. The transmission and authorized access records of each report will be recorded on the blockchain to verify the integrity, authenticity and non-tampering of the report;

[0102] Medical institution database, used for final target medical report data and storage of doctors’ acquisition of user’s family vital sign data measurements and related health reports, and the reports correspond to user identity information in the medical institution database;

[0103] The data exchange center is used to store the target medical report data generated by the report generation module. The index of the report is the anonymous report unique identifier. The report is stored after verifying that the report is the same content stored in the user's smart health home database, providing anonymous access, that is, only through the target unique identifier without obtaining personal identification information, or based on the user's active authorization transaction, allowing doctors to match data and reports based on the user's family vital signs.

[0104] It should be noted that, for the above-mentioned method embodiments, for the sake of simplicity, they are all described as a series of action combinations, but those skilled in the art should know that the present invention is not limited by the described action sequence, because according to the present invention, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present invention.

[0105] According to another aspect of an embodiment of the present invention, a blockchain sharing device based on vital sign data health report is provided for implementing the above-mentioned blockchain sharing method based on vital sign data health report. Figure 8 As shown, the device comprises:

[0106] The acquisition unit 802 is used to acquire a vital sign data health report generated by the user in a home environment, store the target medical report data in the vital sign data health report to the data interaction center based on the target unique identifier and the user public key, and add a first transaction record from the user to the data interaction center on the blockchain, wherein the target unique identifier includes a hash value generated locally by the user;

[0107] The determining unit 804 is used to determine the public key and blockchain address of the target doctor, obtain the target medical report data format and generation time provided by the target doctor, and add a second transaction record from the user to the target doctor on the blockchain when confirming that the user authorizes access to send the report data, the second transaction record includes the user authorizing the designated target doctor to access the target medical report data generated during the designated time period;

[0108] The encryption unit 806 is used to encrypt the target unique identifier corresponding to the target medical report data using the public key of the target doctor, and add a third transaction record from the user to the target doctor on the blockchain, where the third transaction record includes the encrypted target unique identifier sent by the user.

[0109] According to another aspect of an embodiment of the present invention, an electronic device for implementing the above-mentioned blockchain sharing method based on vital sign data health report is also provided, such as Fig. 9 As shown, the electronic device includes a memory 902 and a processor 904. The memory 902 stores a computer program, and the processor 904 is configured to execute the steps in any of the above method embodiments through the computer program.

[0110] Optionally, in this embodiment, the electronic device may be located in at least one network device among a plurality of network devices of a computer network.

[0111] Optionally, in this embodiment, the processor may be configured to perform the following steps through a computer program:

[0112] S1, obtaining a vital sign data health report generated by the user in a home environment, storing the target medical report data in the vital sign data health report to a data interaction center based on the target unique identifier and the user's public key, and adding a first transaction record from the user to the data interaction center on the blockchain, wherein the target unique identifier includes a hash value generated locally by the user;

[0113] S2, determining the public key and blockchain address of the target doctor, obtaining the target medical report data format and generation time provided by the target doctor, and adding a second transaction record from the user to the target doctor on the blockchain when confirming that the user authorizes access to send the report data, the second transaction record includes the user authorizing the designated target doctor to access the target medical report data generated during the specified time period;

[0114] S3, using the public key of the target doctor to encrypt the target unique identifier corresponding to the target medical report data, and adding a third transaction record from the user to the target doctor on the blockchain, the third transaction record includes the encrypted target unique identifier sent by the user.

[0115] Alternatively, a person skilled in the art may understand that: Fig. 9 The structure shown is for illustration only, and the electronic device may also be a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile Internet device (MID), a PAD, or other terminal devices. Fig. 9 The structure of the electronic device is not limited. Fig. 9 More or fewer components (such as network interfaces, etc.) as shown in, or with Fig. 9 Different configurations are shown.

[0116] Among them, the memory 902 can be used to store software programs and modules, such as the program instructions / modules corresponding to the blockchain sharing method and device based on vital signs data health report in the embodiment of the present invention. The processor 904 executes various functional applications and data processing by running the software programs and modules stored in the memory 902, that is, to realize the above-mentioned blockchain sharing method based on vital signs data health report. The memory 902 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 902 may further include a memory remotely arranged relative to the processor 904, and these remote memories may be connected to the terminal via a network. Examples of the above-mentioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Among them, the memory 902 can be specifically, but not limited to, used to store information such as target medical report data. As an example, such as Fig. 9 As shown, the memory 902 may include, but is not limited to, the acquisition unit 802, the determination unit 804, and the encryption unit 806 in the blockchain sharing device based on vital sign data health report. In addition, other module units in the blockchain sharing device based on vital sign data health report may also be included but are not limited to, which will not be repeated in this example.

[0117] Optionally, the transmission device 906 is used to receive or send data via a network. Specific examples of the above-mentioned network may include a wired network and a wireless network. In one example, the transmission device 906 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices and routers via a network cable so as to communicate with the Internet or a local area network. In one example, the transmission device 906 is a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0118] In addition, the electronic device further includes: a display 908 for displaying target medical report data and other information; and a connection bus 910 for connecting various module components in the electronic device.

[0119] According to another aspect of the embodiments of the present invention, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above method embodiments when run.

[0120] Optionally, in this embodiment, the computer-readable storage medium may be configured to store a computer program for performing the following steps:

[0121] S1, obtaining a vital sign data health report generated by the user in a home environment, storing the target medical report data in the vital sign data health report to a data interaction center based on the target unique identifier and the user's public key, and adding a first transaction record from the user to the data interaction center on the blockchain, wherein the target unique identifier includes a hash value generated locally by the user;

[0122] S2, determining the public key and blockchain address of the target doctor, obtaining the target medical report data format and generation time provided by the target doctor, and adding a second transaction record from the user to the target doctor on the blockchain when confirming that the user authorizes access to send the report data, the second transaction record includes the user authorizing the designated target doctor to access the target medical report data generated during the specified time period;

[0123] S3, using the public key of the target doctor to encrypt the target unique identifier corresponding to the target medical report data, and adding a third transaction record from the user to the target doctor on the blockchain, the third transaction record includes the encrypted target unique identifier sent by the user.

[0124] Optionally, in this embodiment, a person of ordinary skill in the art may understand that all or part of the steps in the various methods of the above embodiments may be completed by instructing hardware related to the terminal device through a program, and the program may be stored in a computer-readable storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, etc.

[0125] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

[0126] If the integrated units in the above embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in the above computer-readable storage medium. Based on such understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling one or more computer devices (which can be personal computers, servers or network devices, etc.) to perform all or part of the steps of the methods of various embodiments of the present invention.

[0127] In the above embodiments of the present invention, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0128] In the several embodiments provided in the present application, it should be understood that the disclosed client can be implemented in other ways. Among them, the device embodiments described above are only schematic, for example, the division of units is only a logical function division, and there may be other division methods in actual implementation, for example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0129] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0130] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0131] The above are only preferred embodiments of the present invention. It should be pointed out that, for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A blockchain sharing method based on vital signs data health report, characterized in that: include: Obtain a health report of vital sign data generated by the user in a home environment, store target medical report data in the health report of the vital sign data to a data interaction center based on a target unique identifier and a user public key, and add a first transaction record from the user to the data interaction center on the blockchain, wherein the target unique identifier includes a hash value generated locally by the user; Determine the public key and blockchain address of the target doctor, obtain the target medical report data format and generation time provided by the target doctor, and, upon confirming that the user authorizes access to send the report data, add a second transaction record from the user to the target doctor on the blockchain, wherein the second transaction record includes the user authorizing the target doctor to access the target medical report data generated during a specified time period; The target unique identifier corresponding to the target medical report data is encrypted using the public key of the target doctor, and a third transaction record from the user to the target doctor is added to the blockchain, wherein the third transaction record includes the encrypted target unique identifier sent by the user.

2. A blockchain sharing method based on vital sign data health report according to claim 1, characterized in that: After the third transaction record of adding a user to the target doctor on the blockchain, the process further includes: In the case where the target doctor needs to view the target medical report data, the encrypted target unique identifier is decrypted using the target doctor's private key, and the target medical report data corresponding to the target unique identifier is downloaded from the data exchange center; When the target doctor is determined to accept the target medical report data, the final target medical report data is stored in the user's corresponding database in the central server of the medical institution, and a fourth transaction record from the target doctor to the user is added to the blockchain.

3. A blockchain sharing method based on vital sign data health report according to claim 2, characterized in that: In the case where the target doctor determines to accept the target medical report data, the method further includes: Obtaining a hash value of the target medical report data; comparing the hash value of the target medical report data with the hash value generated locally by the user; When the hash values ​​are consistent, the target doctor determines to accept the target medical report data; when the hash values ​​are inconsistent, the target doctor refuses to accept the target medical report data.

4. The blockchain sharing method based on vital sign data health report according to claim 1 is characterized in that: In the case of confirming that the user authorizes access to the sent report data, adding a second transaction record from the user to the target doctor on the blockchain, the method further includes: In case the user sends a report, generating a first dynamic code; Matching the first dynamic code with the second dynamic code generated by the smart healthy home edge analysis module; In the event that the first dynamic code and the second dynamic code match, it is confirmed that the user is authorized to access the sent report data.

5. The blockchain sharing method based on vital sign data health report according to claim 1 is characterized in that: Determine a target unique identifier, the method comprising: Obtain a concatenated string, and perform a hash calculation on the concatenated string using a hash algorithm to generate a first unique identifier; Detecting whether the first unique identifier is repeated with other unique identifiers stored in the data exchange center; In the case where the first unique identifier is repeated, modify the random number and regenerate the first unique identifier, and repeat the detection step until the first unique identifier is no longer repeated; When there is no duplication of the first unique identifier, the first unique identifier is determined as the target unique identifier.

6. The blockchain sharing method based on vital sign data health report according to claim 1 is characterized in that: Acquiring target medical report data generated by the user in a home environment in the report generating unit also includes: Acquire first signal data in multiple formats through wearable sensors and IoT sensors in smart and healthy homes; Performing data preprocessing and verification on the first signal data to determine second signal data; The second signal data is converted into unified standard format data.

7. The blockchain sharing method based on vital sign data health report according to any one of claims 1 to 6, characterized in that: Classifying the target medical report data and predicting disease risks, including: Extracting features from the target medical report data; Inputting various features of the target medical report data into a trained classification model, wherein the classification model classifies the target medical report data into possible diseases; Inputting various features of the target medical report data into a trained prediction model, wherein the prediction model determines the average distance between the user's current health status and the disease boundary based on historical health data features and current data features, and generates health recommendations; The results obtained by the classification model and the prediction model are displayed on the terminals of the user and the target doctor through a visual interface.

8. A blockchain sharing system based on vital signs data health report, characterized in that: include: A report generation module, used to collect vital sign data of wearable sensors and IoT sensors in a smart and healthy home in a home environment, and generate the target medical report data, wherein the report generation unit includes a sensor and data gateway module and a smart and healthy home edge analysis module; A data interaction module, used for interactive operations between the target medical report data and the blockchain, determining the target unique identifier and the user public key, determining the public key and blockchain address of the target doctor, and encrypting and decrypting the target unique identifier corresponding to the target medical report data using the public key; A data exchange center, used for storing the target medical report data and the corresponding target unique identifier; A corresponding database of the central server of the medical institution is used to store the final target medical report data; Blockchain is used to store target medical report data transmission and access records.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein the program executes the method described in any one of claims 1 to 7 when executed.

Images