A health data sharing method and system based on the Internet of Things

Abstract

This invention discloses a health data sharing method and system based on the Internet of Things (IoT), specifically relating to the field of data sharing technology. It involves collecting raw health data uploaded by IoT terminals, generating an original authorization identifier based on the data source, collection sequence, and user authorization content, then parsing the authorization boundaries of the raw health data to construct a constraint mapping chain. After risk scoring processing to generate derived health data, the constraint mapping chain is synchronously transmitted to the derived health data to form an inherited authorization identifier. Upon receiving a user authorization change instruction, the authorization boundary is reconstructed to achieve dynamic linkage updates of authorization constraints on the derived health data, ensuring consistency between the sharing control results and user authorization.

Description

Technical Field

[0001] This invention relates to the field of data sharing technology, and more specifically, to a method and system for sharing health data based on the Internet of Things. Background Technology

[0002] Existing technologies typically collect raw health data and set initial access authorization scopes to enable users to control the sharing of their own health data. In practical applications, raw health data is often further processed to generate various derived health data. During the sharing process, derived health data gradually deviates from the authorization control boundaries of the original health data, forming an independent data sharing state. This causes the authorization constraints originally applicable to the original health data to fail to effectively extend and continue to affect the derived health data, resulting in an inconsistency between the authorization status of the derived health data when accessed and the authorization requirements initially set by the user. Summary of the Invention

[0003] In order to overcome the above-mentioned defects of the prior art, embodiments of the present invention provide a health data sharing method and system based on the Internet of Things to solve the problems mentioned in the background art.

[0004] To achieve the above objectives, the present invention provides the following technical solution:

[0005] A method for sharing health data based on the Internet of Things includes the following steps:

[0006] S1. Collect raw health data continuously uploaded by IoT terminals and generate corresponding raw authorization identifiers according to data source, collection time sequence and user authorization content;

[0007] S2. Based on the original authorization identifier, parse the authorization boundary of the original health data and construct a constraint mapping chain containing data nodes, authorization nodes and time nodes;

[0008] S3. Perform risk scoring on the raw health data and record the derivation path between the raw health data and the derived health data according to the processing procedure.

[0009] S4. Based on the derived path, the constraint mapping chain is synchronously transmitted to the derived health data, and the inheritance authorization identifier of the corresponding derived health data is generated.

[0010] S5. After receiving the user's authorization change instruction, retrieve the corresponding derived health data and real-time access time according to the inherited authorization identifier, and reconstruct the authorization boundary of the corresponding constraint mapping chain.

[0011] S6. Based on the reconstructed authorization boundary, perform access verification on the derived health data and map the verification results to the shared control results.

[0012] In a preferred embodiment, S1 specifically refers to:

[0013] Collect raw health data continuously uploaded by IoT terminals;

[0014] Extract the data source identifier and collection time sequence marker carried in the raw health data;

[0015] Obtain user-authorized content related to the original health data sharing object that is pre-set by the user within the time range corresponding to the collection time sequence marker;

[0016] The data source identifier, collection time sequence marker, and user authorization content are associated to generate a unique original authorization identifier corresponding to the original health data.

[0017] In a preferred embodiment, S2 specifically refers to:

[0018] Determine the authorization boundaries corresponding to the original health data based on the user-authorized content;

[0019] Extract the data source identifier and collection time sequence marker corresponding to the original health data;

[0020] Map the data source identifier to a data node in the constraint mapping chain;

[0021] Map the acquisition time sequence markers to time nodes in the constraint mapping chain;

[0022] Map the authorization boundaries corresponding to the user-authorized content to authorization nodes in the constraint mapping chain;

[0023] Associate data nodes, authorization nodes, and time nodes to construct a constraint mapping chain corresponding to the original health data.

[0024] In a preferred embodiment, S3 specifically refers to:

[0025] Extract the original health data within the data source boundary corresponding to the data node in the constraint mapping chain;

[0026] The extracted raw health data is processed with risk scoring to generate derived health data;

[0027] Record the start and end times of risk scoring, the processing type identifier, and the original health data fragments called during the processing.

[0028] Write the start and end times of the processing, the processing type identifier, the original health data fragments, and the generated derived health data into the derived path record.

[0029] In a preferred embodiment, S4 specifically refers to:

[0030] Extract the generated derived health data and the corresponding original health data fragments from the derived path records;

[0031] Locate the data nodes, authorization nodes, and time nodes that correspond to the original health data segments in the constraint mapping chain;

[0032] Extract the data source boundary corresponding to the located data node, the shared object boundary corresponding to the authorized node, and the time boundary corresponding to the time node into an authorized boundary constraint set;

[0033] Generate an inheritance authorization identifier that uniquely corresponds to the derived health data, and write the set of authorization boundary constraints into the inheritance authorization identifier.

[0034] In a preferred embodiment, S5 specifically refers to:

[0035] Receive user authorization change instructions and extract the changed user authorization content from the user authorization change instructions;

[0036] Traverse the inheritance authorization identifiers that are bound to the derived health data in the derived path record;

[0037] Extract the authorization boundary constraint set from the inherited authorization identifier. The authorization boundary constraint set includes the data source boundary, the shared object boundary, and the time boundary.

[0038] The modified user authorization content is compared with the set of authorization boundary constraints to determine the boundaries of shared objects affected by the user authorization change instruction;

[0039] Locate the authorization node corresponding to the boundary of the affected shared object in the constraint mapping chain;

[0040] Update the shared object boundaries corresponding to the authorized node based on the changed user authorization content;

[0041] The updated shared object boundaries are rewritten into the set of authorization boundary constraints that inherit the authorization identifier.

[0042] In a preferred embodiment, S6 specifically refers to:

[0043] Obtain access requests to derived health data, and extract the request initiator identifier and request access time from the access requests;

[0044] Locate the inheritance authorization identifier corresponding to the derived health data in the derived path record;

[0045] Extract the authorization boundary constraint set from the inherited authorization identifier. The authorization boundary constraint set includes the data source boundary, the shared object boundary of the shared object after writing and updating, and the time boundary.

[0046] The request initiator's identifier is matched and verified against the shared object boundary, and the request access time is verified against the time boundary.

[0047] When the request initiator's identifier matches the shared object boundary and the request access time is within the time boundary, a shared control result allowing access to derived health data is generated.

[0048] When the request initiator's identifier does not conform to the shared object boundary or the request access time exceeds the time boundary, a sharing control result of denying access to derived health data is generated.

[0049] On the other hand, the present invention provides a health data sharing system based on the Internet of Things, comprising:

[0050] Original Authorization Module: Collects raw health data continuously uploaded by IoT terminals and generates corresponding original authorization identifiers according to data source, collection time sequence and user authorization content;

[0051] Mapping Module: Based on the original authorization identifier, the authorization boundary of the original health data is parsed, and a constraint mapping chain containing data nodes, authorization nodes, and time nodes is constructed.

[0052] Inheritance authorization module: performs risk scoring on the original health data and records the derivation path between the original health data and derived health data according to the processing procedure;

[0053] Path recording module: Based on the derived path, the constraint mapping chain is synchronously transmitted to the derived health data, and the inheritance authorization identifier of the corresponding derived health data is generated;

[0054] Boundary Reconstruction Module: After receiving the user's authorization change instruction, it retrieves the corresponding derived health data and real-time access time according to the inherited authorization identifier, and reconstructs the authorization boundary of the corresponding constraint mapping chain;

[0055] Access verification module: Based on the reconstructed authorization boundary, it performs access verification on derived health data and maps the verification results to the shared control results.

[0056] The technical effects and advantages of the health data sharing method and system based on the Internet of Things of this invention are as follows:

[0057] By collecting raw health data continuously uploaded from IoT terminals and generating original authorization identifiers based on data source, collection sequence, and user authorization content, each piece of raw health data has an authorization basis when entering the sharing process. A constraint mapping chain containing data nodes, authorization nodes, and time nodes is constructed to create a traceable link between the source, time, and authorization boundaries of the raw health data. During risk scoring, the derivation path between raw health data and derived health data is recorded, allowing derived health data to be mapped back to the original health data that generated it. The constraint mapping chain is synchronously transmitted to the derived health data and an inherited authorization identifier is generated, extending the original authorization constraints to the derived health data. After a user authorization change, the authorization boundaries of the constraint mapping chain are reconstructed, ensuring that the authorization change applies to the generated derived health data. Access verification is performed based on the reconstructed authorization boundaries, ensuring that the sharing control results of the derived health data are consistent with the latest user authorization content. Attached Figure Description

[0058] Figure 1 This is a schematic diagram of a health data sharing method based on the Internet of Things according to the present invention;

[0059] Figure 2 This is a schematic diagram of the structure of a health data sharing system based on the Internet of Things according to the present invention. Detailed Implementation

[0060] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0061] Example 1

[0062] Figure 1 This invention provides a method for sharing health data based on the Internet of Things, which includes the following steps:

[0063] S1. Collect raw health data continuously uploaded by IoT terminals and generate corresponding raw authorization identifiers according to data source, collection time sequence and user authorization content;

[0064] S2. Based on the original authorization identifier, parse the authorization boundary of the original health data and construct a constraint mapping chain containing data nodes, authorization nodes and time nodes;

[0065] S3. Perform risk scoring on the raw health data and record the derivation path between the raw health data and the derived health data according to the processing procedure.

[0066] S4. Based on the derived path, the constraint mapping chain is synchronously transmitted to the derived health data, and the inheritance authorization identifier of the corresponding derived health data is generated.

[0067] S5. After receiving the user's authorization change instruction, retrieve the corresponding derived health data and real-time access time according to the inherited authorization identifier, and reconstruct the authorization boundary of the corresponding constraint mapping chain.

[0068] S6. Based on the reconstructed authorization boundary, perform access verification on the derived health data and map the verification results to the shared control results.

[0069] S1. Collect raw health data continuously uploaded by IoT terminals, and generate corresponding raw authorization identifiers according to data source, collection sequence, and user-authorized content, including:

[0070] Collect raw health data continuously uploaded by IoT terminals;

[0071] Specifically, IoT terminals include, but are not limited to, health monitoring devices such as smart bracelets, wearable ECG monitors, or smart blood glucose monitors; IoT terminals continuously record users' health physiological indicators and form data streams, including but not limited to users' heart rate, blood pressure, blood glucose, sleep status, or exercise data; IoT terminals continuously upload the recorded raw health data to a health data receiving server at fixed or dynamically adjusted time intervals, such as every minute, every five minutes, or any interval set by the user, via wireless communication, such as through a wireless local area network or mobile cellular network.

[0072] Extract the data source identifier and collection time sequence marker carried in the raw health data;

[0073] Specifically, the data source identifier is the unique identifier of the IoT terminal device, such as the International Mobile Equipment Identity (IMEI), Media Access Control Address (MAC address), or serial number assigned by the manufacturer and embedded during device manufacturing; the collection time sequence mark is a timestamp automatically attached by the IoT terminal when collecting each piece of raw health data, accurate to the second or millisecond, and marked in the international standard time (UTC) format to ensure the global uniqueness and accuracy of the collection time sequence; the health data receiving server extracts the data source identifier and collection time sequence mark from the received raw health data packets by parsing fixed fields in the packet header.

[0074] Obtain user-authorized content related to the original health data sharing object that is pre-set by the user within the time range corresponding to the collection time sequence marker;

[0075] Specifically, the user-authorized content is set in advance by the user through the authorization management interface, which is provided via a mobile application or web page. After authentication, the user specifies the sharing objects for their own health data. The sharing objects include, but are not limited to, hospitals, family doctors, health insurance institutions, or third-party health management platforms. When setting the sharing objects in the authorization management interface, the user needs to specify the valid time period of the authorization, such as setting it to be valid indefinitely, a specified date range, or valid within a specific time period. After the health data receiving server receives the raw health data and extracts the collection time sequence mark, it determines the time of collection of the raw health data based on the collection time sequence mark, and retrieves the user-authorized content corresponding to the raw health data in the user authorization database with the collection time as the index.

[0076] Associate the data source identifier, collection time sequence marker, and user authorization content to generate a unique original authorization identifier corresponding to the original health data;

[0077] Specifically, the health data receiving server constructs a composite data structure consisting of a data source identifier, a collection time sequence marker, and user authorization content. For example, the data source identifier, collection time sequence marker, and user authorization content are encoded into intermediate data items in binary or string format, and these intermediate data items are connected in a specific order to form an initial authorization sequence. To ensure the uniqueness and tamper-proof nature of the original authorization identifier, the health data receiving server processes the initial authorization sequence using a specific digest algorithm, such as a secure hash algorithm (SHA-256). The output of the digest algorithm is a fixed-length string, which serves as the original authorization identifier that uniquely corresponds to the original health data.

[0078] S2. Based on the original authorization identifier, parse the authorization boundary of the original health data and construct a constraint mapping chain containing data nodes, authorization nodes, and time nodes, including:

[0079] Determine the authorization boundaries corresponding to the original health data based on the user-authorized content;

[0080] Specifically, the user-authorized content is set in advance by the user through the authorization management interface, limiting the target objects and valid time range for sharing the original health data. The target objects include, but are not limited to, designated hospitals, family doctors, health insurance institutions, or third-party health management platforms. The valid time range includes, but is not limited to, long-term validity, validity within a specific date range, or validity within a specific time period each day. After receiving the user-authorized content, the health data receiving server parses the user-authorized content, records the information of the sharing target objects and the sharing valid time range in the user-authorized content, determines the boundary of the sharing object based on the description of the sharing target object, and determines the sharing time boundary based on the description of the sharing valid time range, thereby defining the authorization boundary corresponding to the original health data. For example, when the user-authorized content sets the sharing object to a designated family doctor, the boundary of the sharing object is the user account identifier associated with the corresponding family doctor; when the user-authorized content sets the valid time range to 08:00-20:00 on a certain day, the sharing time boundary is the time period between 08:00 and 20:00 every day.

[0081] Extract the data source identifier and collection time sequence marker corresponding to the original health data;

[0082] Specifically, the health data receiving server extracts the data source identifier and collection time sequence mark from the composite data structure of the stored raw health data. The data source identifier is a unique device identifier that is fixed during the manufacturing process of the IoT terminal, such as, but not limited to, the International Mobile Equipment Identity (IMEI), the Media Access Control Address (MAC address), or the serial number assigned by the manufacturer. The collection time sequence mark is an International Standard Time (UTC) timestamp that is automatically attached by the IoT terminal when generating each piece of raw health data, provided in the form of precise seconds or milliseconds. The health data receiving server obtains the collection time sequence mark by parsing the fixed timestamp field in the data structure of the raw health data.

[0083] Map the data source identifier to a data node in the constraint mapping chain;

[0084] Specifically, the health data receiving server maps the obtained data source identifier as a key identification element in the constraint mapping chain: generating a constraint mapping chain data structure, including but not limited to data nodes, authorization nodes, and time nodes; wherein, a data node is defined as a unique node used to define the data source in the constraint mapping chain, and the unique identifier of the unique node is the data source identifier itself; for example, if the data source identifier is the MAC address "00:1A:7D:DA:71:13", then the data node uses the above MAC address as the node identifier and records it in the constraint mapping chain, indicating the identity of the data source device associated with the constraint mapping chain.

[0085] Map the acquisition time sequence markers to time nodes in the constraint mapping chain;

[0086] Specifically, the health data receiving server determines the collection time period corresponding to the collection time sequence mark based on the collection time sequence mark, and records it as a time node in the constraint mapping chain. The health data receiving server uses the collection time sequence mark as a reference to accurately map the collection time sequence mark to a specific time node. For example, if the collection time sequence mark is "2024-05-14T14:23:05.005Z", the health data receiving server accurately maps this time to the collection time node corresponding to the time point and records it in the constraint mapping chain, thereby forming a time node in the constraint mapping chain, which is used to limit the time attribute of the data corresponding to the data node.

[0087] Map the authorization boundaries corresponding to the user-authorized content to authorization nodes in the constraint mapping chain;

[0088] Specifically, the health data receiving server constructs authorized nodes in a constraint mapping chain based on the shared object boundaries and shared time boundaries in the user-authorized content. It maps the shared object boundaries to the authorized nodes in the constraint mapping chain to define the shared objects that can access or share data in the data nodes. Simultaneously, it maps the shared time boundaries to the same authorized node to determine the valid time period for accessing data in the data nodes. For example, if the shared object boundary is determined to be the user account identifier of a specific family doctor, and the shared time boundary is determined to be 08:00-20:00 daily, then the authorized node records the shared constraints formed by the family doctor's account identifier and the above time period as its node content.

[0089] Associate data nodes, authorization nodes, and time nodes to construct a constraint mapping chain corresponding to the original health data;

[0090] Specifically, the health data receiving server combines the identified data nodes, authorization nodes, and time nodes using association rules to form a constraint mapping chain. It associates the data source identifier in the data node with the collection time in the time node to represent the raw health data generated by a device from a specific data source at a specific time. Simultaneously, it associates the combined result with the authorization node to limit the applicable sharing objects and sharing time for data generated by a specific data source device at a specific time. The specific data structure can be a directed graph or a linked list structure. For example, it can be implemented using a linked list structure, where each node records the data node identifier, time node identifier, and authorization node identifier, and the nodes are linked through pointers or association identifiers. The final constraint mapping chain starts with the data node and sequentially connects the time node and the authorization node, representing the authorization scope and constraint relationships corresponding to the raw health data.

[0091] S3. Perform risk scoring on the raw health data, and record the derivation path between the raw health data and the derived health data according to the processing procedure, including:

[0092] Extract the original health data within the data source boundary corresponding to the data node in the constraint mapping chain;

[0093] Specifically, after constructing the constraint mapping chain, the health data receiving server uses the data nodes in the constraint mapping chain as the retrieval entry point for raw health data. The data source identifier recorded in the data node is used to limit the range of source devices for the raw health data. The health data receiving server reads the data source identifier in the data node and performs data retrieval in the raw health data storage area based on the data source identifier. In the raw health data storage area, each piece of raw health data is associated with and stored with its corresponding original authorization identifier, collection time sequence marker, and data source identifier. Therefore, the health data receiving server can filter out all raw health data generated by the corresponding device based on the data source identifier in the data node. The health data receiving server reads the time nodes in the constraint mapping chain; the data collection time recorded in the time nodes is used to limit the valid time range of the raw health data. The receiving server performs time filtering on the selected raw health data based on the collection time in the time node to obtain the raw health data within the target time range corresponding to the time node. For example, when the collection time range corresponding to the time node is from "2024-05-14T08:00:00.000Z" to "2024-05-14T20:00:00.000Z", the health data receiving server only retains the raw health data whose collection time sequence mark is within the above time range. The health data receiving server reads the shared object boundary and shared time boundary in the authorization node and performs consistency verification between the shared object boundary and shared time boundary and the original authorization identifier corresponding to the selected raw health data to ensure that the extracted raw health data simultaneously meets the constraints of the data source boundary, time boundary, and authorization boundary.

[0094] The extracted raw health data is processed with risk scoring to generate derived health data;

[0095] Specifically, the health data receiving server performs format standardization processing on the extracted raw health data to unify the data structure of data uploaded from different IoT terminals. Format standardization includes field unification, timeline alignment, and outlier removal. Field unification converts different field names uploaded from different IoT terminals into unified field names. Timeline alignment maps raw health data with different sampling frequencies to a unified time interval; for example, it maps heart rate data collected every 30 seconds and blood glucose data collected every 5 minutes to a 1-minute time granularity. Outlier removal removes data that exceeds reasonable physiological ranges; for example, when the heart rate is less than 20 beats / minute or greater than 250 beats / minute, the corresponding data is marked as outlier. The data is removed from the risk scoring process; after completing the format standardization process, the health data receiving server performs risk scoring on the original health data; risk scoring refers to the process of numerically assessing the probability of a user experiencing a target health event within a preset time frame based on the continuous changes in the user's health status reflected in the original health data; target health events include, but are not limited to, risks of hyperglycemia, abnormal heart rate, sleep disorders, or exercise load; the health data receiving server extracts continuous physiological feature sequences from the original health data, including continuous heart rate sequences, continuous blood glucose sequences, and continuous sleep duration sequences; the health data receiving server calculates the risk score value based on the continuous physiological feature sequences.

[0096] The risk score is calculated using the following formula: ;

[0097] in, This represents a risk score, used to indicate the degree of risk of a target health event occurring within a preset time frame; This represents the risk weight value corresponding to the kth continuous physiological characteristic sequence, which is used to indicate the magnitude of the impact of different continuous physiological characteristic sequences on the target health event. This represents the standardized eigenvalue corresponding to the k-th continuous physiological characteristic sequence; This indicates the number of consecutive physiological feature sequences involved in the risk scoring process.

[0098] Risk weights are set based on the correlation strength between historical health event data and continuous physiological characteristic sequences. The health data receiving server calculates the correlation coefficient between each continuous physiological characteristic sequence in the historical health event data and the target health event, and then normalizes the risk weights based on the correlation coefficient. For example, when the correlation coefficient between a continuous blood glucose sequence and the risk of hyperglycemia is higher than that between a continuous sleep duration sequence and the risk of hyperglycemia, the risk weight value corresponding to the continuous blood glucose sequence is higher than that corresponding to the continuous sleep duration sequence. Standardized feature values ​​are obtained by performing maximum-minimum value normalization on the continuous physiological characteristic sequences in the original health data. The minimum value normalization process involves subtracting the historical minimum value from the current continuous physiological characteristic value, and then dividing by the difference between the historical maximum and the historical minimum value, thereby obtaining a standardized characteristic value ranging from 0 to 1. The health data receiving server generates corresponding derived health data based on the calculated risk score value. The derived health data includes the risk score value, risk level identifier, and risk generation time. The risk level identifier is determined based on the range to which the risk score value belongs. For example, a risk score value less than 0.3 is determined to be a low risk level, a risk score value between 0.3 and 0.7 is determined to be a medium risk level, and a risk score value greater than 0.7 is determined to be a high risk level.

[0099] Record the start and end times of risk scoring, the processing type identifier, and the original health data fragments called during the processing.

[0100] Specifically, when initiating risk scoring processing, the health data receiving server records the start time of the risk scoring process and the end time of the risk scoring process. Both the start and end times are recorded in UTC format to ensure time consistency during the derived path tracing process. The health data receiving server generates a processing type identifier corresponding to the risk scoring process, which is used to distinguish different data processing methods. For example, when the risk scoring process corresponds to hyperglycemia risk analysis, the processing type identifier can be set to "RISK_GLUCOSE_001"; when the risk scoring process corresponds to abnormal heart rate analysis, the processing type identifier can be set to "RISK_HEARTRATE_001". The generation method of the processing type identifier includes, but is not limited to, generating a string code by combining the processing target category, processing algorithm category, and processing time order.

[0101] During the risk scoring process, the health data receiving server records the original health data segments involved in the risk scoring process. An original health data segment refers to the set of data actually accessed during the risk scoring process. The original health data segment includes the data source identifier, the collection time sequence marker, and the original health data itself. For example, when the risk scoring process accesses continuous heart rate data between "2024-05-14T08:01:00.000Z" and "2024-05-14T08:30:00.000Z", the health data receiving server records the complete original health data segment corresponding to the continuous heart rate data.

[0102] Write the start and end times of processing, processing type identifier, original health data fragments, and generated derived health data into the derived path record;

[0103] Specifically, after generating derived health data, the health data receiving server constructs a derived path record corresponding to the derived health data. The derived path record records the complete data derivation relationship from the generation of the original health data to subsequent sharing. The health data receiving server generates a derived path record identifier, which is generated as a unique string, for example, by combining the processing start and end times, processing type identifier, and the risk score value corresponding to the derived health data and then performing a secure hash algorithm. The health data receiving server writes the processing start time, processing end time, processing type identifier, original health data fragment, and derived health data into the derived path record according to a fixed field order. The data structure of the derived path record includes, but is not limited to, a linked list structure, a directed graph structure, or a time series structure. For example, when using a linked list structure, the first node records the derived path record identifier, the middle nodes sequentially record the processing start time, processing end time, and processing type identifier, and the tail node records the association relationship between the original health data fragment and the derived health data. After completing the writing of the derived path record, the health data receiving server binds the derived path record to the original authorization identifier.

[0104] S4. Based on the derivation path, synchronously transfer the constraint mapping chain to the derived health data, and generate the inheritance authorization identifier for the corresponding derived health data, including:

[0105] Extract the generated derived health data and the corresponding original health data fragments from the derived path records;

[0106] Specifically, the health data receiving server locates the derived path record identifier recorded in the derived path record storage area, and obtains the derived health data content and original health data fragments in the record through the derived path record identifier. The derived path record identifier is a unique identifier string generated by combining the processing start time, processing end time, processing type identifier, and the risk score value corresponding to the derived health data through a specific secure hash algorithm (SHA-256), thereby ensuring the uniqueness and tamper-proof nature of each derived path record. The health data receiving server reads the content of the derived health data from the derived path records, including the risk score value, risk level identifier, and risk generation time, and extracts the original health data fragments associated with the derived health data, including the original health data itself, data source identifier, and collection time sequence marker.

[0107] Locate the data nodes, authorization nodes, and time nodes that correspond to the original health data segments in the constraint mapping chain;

[0108] Specifically, the health data receiving server performs node matching and location step-by-step within the stored constraint mapping chain data structure based on the data source identifier and acquisition time sequence marker in the original health data fragment. Using the data source identifier in the original health data fragment as a key location element, the server matches nodes within the data node set in the constraint mapping chain to determine the data node corresponding to the original health data fragment. For example, when the data source identifier in the original health data fragment is the MAC address "00:1A:7D:DA:71:13", the health data receiving server searches for the data node with the identifier "00:1A:7D:DA:71:13" in the constraint mapping chain and confirms that the data source device defined by the data node matches the original health data fragment. The data sources are consistent; the health data receiving server continues to use the collection time sequence mark as a reference to locate the time node associated with the data node. Specifically, it compares the collection time sequence mark in the original health data segment with the time node in the constraint mapping chain. For example, if the collection time sequence mark is "2024-05-14T08:01:00.000Z", the health data receiving server searches for the time node in the constraint mapping chain that matches the collection time sequence mark. Based on the location results of the data node and the time node, the health data receiving server locates the commonly associated authorized node to determine the authorized boundary of the derived health data. For example, through the path determined by the combination of data node and time node, it associates with a specific authorized node in the constraint mapping chain to obtain the authorized boundary corresponding to the original health data segment.

[0109] Extract the data source boundary corresponding to the located data node, the shared object boundary corresponding to the authorized node, and the time boundary corresponding to the time node into an authorized boundary constraint set;

[0110] Specifically, the health data receiving server reads the boundary information from the data node, authorization node, and time node to form an authorization boundary constraint set. The data source boundary corresponding to the data node is the data source identifier itself, used to determine the range of data source devices from which the derived health data is constrained. The shared object boundary corresponding to the authorization node is the account identifier of the shared target object explicitly specified by the user in the authorization management interface, including but not limited to the family doctor account identifier, specific hospital account identifier, or health insurance institution account identifier. The time boundary corresponding to the time node is the valid sharing time period specified by the user in the authorization management interface. The health data receiving server reads the above boundary information and stores the boundary information in the authorization boundary constraint set in the form of a data structure.

[0111] Generate an inheritance authorization identifier that uniquely corresponds to the derived health data, and write the set of authorization boundary constraints into the inheritance authorization identifier;

[0112] Specifically, the health data receiving server constructs an inheritance authorization identifier corresponding to the derived health data: The server extracts the risk score, risk level identifier, and risk generation time recorded in the derived health data, combining them to form an initial inheritance authorization sequence; the initial inheritance authorization sequence is merged with the authorization boundary constraint set, and the boundary information of the initial inheritance authorization sequence and the authorization boundary constraint set are connected in a fixed order to form a complete inheritance authorization sequence; for example, the health data receiving server sequentially connects the risk score, risk level identifier, risk generation time, data source boundary, shared object boundary, and time boundary to obtain the inheritance authorization sequence; the health data receiving server uses a secure hash algorithm (SHA-256) to perform a digest algorithm on the inheritance authorization sequence, and the digest algorithm... The output of the method is a fixed-length inherited authorization identifier string, the length of which can be set to 64 hexadecimal characters to ensure the global uniqueness and data security of the inherited authorization identifier. After the inherited authorization identifier is generated, the health data receiving server writes the contents of the authorization boundary constraint set into the record area corresponding to the inherited authorization identifier. For example, the data record area corresponding to the inherited authorization identifier contains complete data source boundaries, shared object boundaries, and time boundaries to ensure accurate and precise access control of derived health data in real time when authorization changes or data sharing requests occur. The data recording method can use a relational database or a non-relational database. For example, in a relational database, the inherited authorization identifier is used as the primary key index, and the corresponding boundary information is stored as record fields.

[0113] S5. After receiving the user's authorization change instruction, retrieve the corresponding derived health data and real-time access time according to the inherited authorization identifier, and reconstruct the authorization boundary of the corresponding constraint mapping chain, including:

[0114] Receive user authorization change instructions and extract the changed user authorization content from the user authorization change instructions;

[0115] Specifically, user authorization change instructions are generated through the user authorization management interface, which provides a mobile application interface or a web interface for user operation. The user authorization management interface includes an authorization settings area where users specify the authorization content to be changed after completing identity verification. Changes to authorization content include, but are not limited to, adding, deleting, or modifying shared object boundaries, as well as extending, shortening, or adjusting shared time boundaries. For example, a user might specify in the authorization settings area that they are changing the shared object boundaries, changing the shared object from a specific hospital account identifier to a specific family doctor account identifier, or adjusting the shared time boundaries, such as from the original authorized time range... The daily 08:00-20:00 period has been changed to daily 10:00-18:00. After the user completes the change operation, the authorization management interface encodes the changed content into a structured data format, such as JavaScript Object Notation (JSON) or Extensible Markup Language (XML), and transmits the user authorization change instruction to the health data receiving server through a secure network communication protocol, such as HTTPS. After receiving the user authorization change instruction, the health data receiving server immediately decodes the user authorization change instruction, parses the data structure of the user authorization change instruction, and extracts the shared object boundaries and shared time boundaries contained in the changed user authorization content.

[0116] Traverse the inheritance authorization identifiers that are bound to the derived health data in the derived path record;

[0117] Specifically, after receiving a user authorization change instruction and extracting the changed user authorization content, the health data receiving server traverses all derived path records in the storage area based on the derived path records to determine the inherited authorization identifier that is bound to each derived health data. Each derived path record records the risk score value, risk level identifier, risk generation time, original health data fragment, processing start and end times, and processing type identifier generated by the derived health data, and is bound to the inherited authorization identifier. The inherited authorization identifier is determined by the risk score value, risk level identifier, risk generation time, and data source boundary. The shared object boundary and time boundary are processed by a secure hash algorithm (SHA-256) to obtain a fixed-length string; during the traversal, the health data receiving server matches the binding relationship between derived path records and inherited authorization identifiers, and retrieves the inherited authorization identifier associated with each derived path record from the database through the derived path record identifier to form an inherited authorization identifier set; for example, when the derived path record identifier is a hash value "D3FA1C54E…", the bound inherited authorization identifier is extracted from the database storage record, such as "8E9F2AB3C…", and recorded in the inherited authorization identifier set.

[0118] Extract the set of authorization boundary constraints from the inherited authorization identifier;

[0119] Specifically, the authorization boundary constraint set includes the data source boundary, the shared object boundary, and the time boundary; the health data receiving server parses the data content for each inherited authorization identifier in the inherited authorization identifier set; the authorization boundary constraint set corresponding to each inherited authorization identifier is stored in the data record area uniquely associated with the inherited authorization identifier, and the data record area includes the data source boundary, the shared object boundary, and the time boundary; the data source boundary is the unique identifier of the data source device; the shared object boundary is the shared target object account identifier set by the user in the user authorization management interface; the time boundary is the valid sharing period set by the user.

[0120] The modified user authorization content is compared with the set of authorization boundary constraints to determine the boundaries of shared objects affected by the user authorization change instruction;

[0121] Specifically, the health data receiving server compares the shared object boundaries in the modified user authorization content with the shared object boundaries in the set of authorization boundary constraints corresponding to each inherited authorization identifier. By comparing the account identifier strings of the authorization object boundaries, when a difference is found, it is determined that the shared object boundary is affected by the user authorization change instruction. For example, when the shared object boundary corresponding to the original inherited authorization identifier is "Hospital_Account_002" and the modified user authorization content is specified as "FamilyDoctor_Account_001", the health data receiving server determines that the shared object boundary is a shared object boundary affected by the user authorization change instruction.

[0122] Locate the authorization node corresponding to the boundary of the affected shared object in the constraint mapping chain;

[0123] Specifically, the health data receiving server uses the boundary of the shared object affected by the user's authorization change instruction as the key identifier, traversing the constructed constraint mapping chain to determine the authorization node that corresponds to the shared object boundary. The authorization node records the complete authorization range of the shared object boundary and the shared time boundary. The health data receiving server searches for the authorization node that matches the affected shared object boundary by traversing the shared object boundary field of the authorization node. For example, when the affected shared object boundary is "Hospital_Account_002", the health data receiving server locates the authorization node in the constraint mapping chain whose shared object boundary field is "Hospital_Account_002".

[0124] Update the shared object boundaries corresponding to the authorized node based on the changed user authorization content;

[0125] Specifically, after the health data receiving server locates the authorized node, it updates the shared object boundary corresponding to the authorized node with the changed user authorization content extracted from the user authorization change instruction. For example, it modifies the shared object boundary "Hospital_Account_002" recorded in the authorized node to the user's latest set shared object boundary "FamilyDoctor_Account_001". The update operation is completed by replacing data fields, and the changed shared object boundary replaces the original shared object boundary in the form of a text string, ensuring that the shared object boundary corresponding to the authorized node is consistent with the changed user authorization content in the user authorization change instruction.

[0126] Rewrite the updated shared object boundaries into the set of authorization boundary constraints that inherit the authorization identifier;

[0127] Specifically, after updating the shared object boundaries in the authorized nodes, the health data receiving server rewrites the updated shared object boundaries in a structured data format into the authorized boundary constraint set record area corresponding to the inherited authorized identifier. The health data receiving server extracts the updated shared object boundaries, for example, "FamilyDoctor_Account_001", and replaces the original shared object boundary field in the record area corresponding to the inherited authorized identifier with the updated shared object boundary field. The updated authorized boundary constraint set is represented as {"Data Source Boundary":"00:1A:7D:DA:71:13"}. The health data receiving server binds and stores the inherited authorization identifier with the latest updated set of authorization boundary constraints. The storage method includes, but is not limited to, updating the record fields in a relational database. This ensures that the latest user authorization changes are accurately transmitted to the inherited authorization boundary of the derived health data, thereby achieving real-time, consistent, and traceable access control for derived health data.

[0128] S6. Based on the reconstructed authorization boundaries, perform access verification on derived health data and map the verification results to the shared control results, including:

[0129] Obtain access requests to derived health data, and extract the request initiator identifier and request access time from the access requests;

[0130] Specifically, the access request is initiated by the access terminal, which includes, but is not limited to, hospital workstation terminals, family doctor mobile terminals, or third-party health management platform terminals. When requesting access to derived health data, the access terminal sends an access request data packet to the health data receiving server. The access request data packet includes at least the request initiator identifier, the request access time, the derived health data identifier, and the access type identifier. The request initiator identifier is used to uniquely identify the access subject requesting access to the derived health data, and the request initiator identifier includes, but is not limited to, hospital account identifier, family doctor account identifier, or health insurance institution account identifier. The request access time is an International Standard Time (UTC) timestamp automatically generated when the access terminal initiates the access request, accurate to the second or millisecond level. After receiving the access request data packet, the health data receiving server decodes the access request data packet and parses the structured fields in the access request data packet. The health data receiving server extracts the request initiator identifier and the request access time from the access request data packet and stores the request initiator identifier and the request access time as independent fields in the memory cache area for later use in the access verification process.

[0131] Locate the inheritance authorization identifier corresponding to the derived health data in the derived path record;

[0132] Specifically, after extracting the request initiator's identifier and the request access time, the health data receiving server retrieves data in the derived path record storage area based on the derived health data identifier contained in the access request data packet. In the derived path record storage area, each derived path record records the binding relationship between derived health data and inherited authorization identifiers. The health data receiving server reads the derived health data identifier from the access request data packet and then performs a matching search in the derived path record storage area based on the derived health data identifier to determine the derived path record that corresponds to the derived health data. For example, when the derived health data identifier is "RiskData_20240514_001", the health data receiving server... The derived path record storage area is searched for record fields that match "RiskData_20240514_001". After locating the corresponding derived path record, the health data receiving server reads the inherited authorization identifier bound to the derived path record. The inherited authorization identifier is a fixed-length string generated by combining the risk score value, risk level identifier, risk generation time, data source boundary, shared object boundary, and time boundary, and then processed by a secure hash algorithm (SHA-256). For example, the inherited authorization identifier can be represented as a 64-bit hexadecimal string in the form of "8E9F2AB3C5D7F9A1E...". The health data receiving server loads the located inherited authorization identifier into the memory cache area.

[0133] Extract the set of authorization boundary constraints from the inherited authorization identifier;

[0134] Specifically, the health data receiving server parses fields in the data record area corresponding to the inherited authorization identifier obtained from location tracking. Within this data record area, a set of authorization boundary constraints bound to the inherited authorization identifier is stored. This set includes data source boundaries, shared object boundaries, and time boundaries. The data source boundary limits the range of IoT terminal devices from which derived health data originates; it is a unique device identifier for the IoT terminal, such as an International Mobile Equipment Identity (IMEI), Media Access Control Address (MAC address), or a serial number assigned by the manufacturer. The shared object boundary limits access to the derived health data. The target access subject scope of the data is defined as follows: the shared object boundary is a data field that is rewritten with the inherited authorization identifier after the user authorization is changed, for example, the shared object boundary is represented as "FamilyDoctor_Account_001"; the time boundary is used to limit the valid access time range for the derived health data, and the time boundary is represented as a time interval, for example, "2024-05-14T08:00:00Z to 2024-06-14T20:00:00Z"; the health data receiving server parses the data source boundary, shared object boundary and time boundary in the authorization boundary constraint set one by one, and loads them into the access verification cache area in the form of structured data.

[0135] The request initiator's identifier is matched and verified against the shared object boundary, and the request access time is verified against the time boundary.

[0136] Specifically, the health data receiving server performs a matching verification between the request initiator identifier and the shared object boundary. The matching verification method is a character-by-character string consistency comparison. The health data receiving server extracts the request initiator identifier from the access request data packet and performs a character-by-character matching with the shared object boundary in the authorized boundary constraint set to determine whether the request initiator identifier matches the shared object boundary. When the request initiator identifier is "Hospital_Account_002" and the shared object boundary is "FamilyDoctor_Account_001", the health data receiving server determines that the request initiator identifier and the shared object boundary are inconsistent. The health data receiving server completes the matching of the request initiator identifier... After verifying the match between the request access time and the shared object boundary, a timeliness check is performed between the request access time and the time boundary. The time boundary consists of a start time and an end time. The health data receiving server converts the request access time into a unified time format and compares it with the start time and end time in the time boundary. The health data receiving server determines whether the request access time is within the valid time range corresponding to the time boundary. When the request access time exceeds the end time, the health data receiving server determines that the request access time is not within the valid time range corresponding to the time boundary. The health data receiving server writes the matching result between the request initiator identifier and the shared object boundary, as well as the timeliness check result between the request access time and the time boundary, into the access check result cache area.

[0137] When the request initiator's identifier matches the shared object boundary and the request access time is within the time boundary, a shared control result allowing access to derived health data is generated.

[0138] Specifically, the health data receiving server reads the matching results and timeliness verification results from the access verification result cache area. When the matching result indicates that the request initiator identifier matches the boundary of the shared object and the timeliness verification result indicates that the requested access time is within the valid time range corresponding to the time boundary, the health data receiving server generates a shared control result that allows access to derived health data. The shared control result includes an access status field, an access authorization field, and an access record field. The access status field is recorded as "ALLOW". The access authorization field records the identifier of the derived health data that is allowed to be accessed. The access record field records the request initiator identifier, the requested access time, and the inherited authorization identifier. The health data receiving server returns the shared control result that allows access to derived health data to the access terminal and simultaneously writes the shared control result that allows access to derived health data to the access log storage area to form a complete access record chain.

[0139] When the request initiator's identifier does not conform to the shared object boundary or the request access time exceeds the time boundary, a sharing control result of denying access to derived health data is generated.

[0140] Specifically, the health data receiving server reads the matching results and timeliness verification results from the access verification result cache area. When the matching result indicates that the request initiator's identifier is inconsistent with the shared object boundary, or the timeliness verification result indicates that the requested access time exceeds the valid time range corresponding to the time boundary, the health data receiving server generates a shared control result for denying access to derived health data. The shared control result includes an access status field, a denial reason field, and an access record field. The access status field is recorded as "DENY". The denial reason field records the specific reason for denying access, including but not limited to "shared object boundary verification failed" or "time boundary verification failed". The access record field records the request initiator's identifier, the requested access time, and the inherited authorization identifier. For example, when... When the request initiator is identified as “Hospital_Account_002” and the shared object boundary is “FamilyDoctor_Account_001”, the rejection reason field is recorded as “Shared object boundary verification failed”; when the requested access time is “2024-07-01T10:15:05.005Z” and the time boundary end time is “2024-06-14T20:00:00Z”, the rejection reason field is recorded as “Time boundary verification failed”; the health data receiving server returns the sharing control result of rejecting access to derived health data to the access terminal, and simultaneously writes the sharing control result of rejecting access to derived health data to the access log storage area to ensure complete traceability and auditing of access behavior.

[0141] Example 2

[0142] The difference between Embodiment 2 and Embodiment 1 is that this embodiment introduces a health data sharing system based on the Internet of Things.

[0143] Figure 2 A schematic diagram of the structure of an IoT-based health data sharing system is provided. The IoT-based health data sharing system includes:

[0144] Original Authorization Module: Collects raw health data continuously uploaded by IoT terminals and generates corresponding original authorization identifiers according to data source, collection time sequence and user authorization content;

[0145] Mapping Module: Based on the original authorization identifier, the authorization boundary of the original health data is parsed, and a constraint mapping chain containing data nodes, authorization nodes, and time nodes is constructed.

[0146] Inheritance authorization module: performs risk scoring on the original health data and records the derivation path between the original health data and derived health data according to the processing procedure;

[0147] Path recording module: Based on the derived path, the constraint mapping chain is synchronously transmitted to the derived health data, and the inheritance authorization identifier of the corresponding derived health data is generated;

[0148] Boundary Reconstruction Module: After receiving the user's authorization change instruction, it retrieves the corresponding derived health data and real-time access time according to the inherited authorization identifier, and reconstructs the authorization boundary of the corresponding constraint mapping chain;

[0149] Access verification module: Based on the reconstructed authorization boundary, it performs access verification on derived health data and maps the verification results to the shared control results.

[0150] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. The semiconductor medium can be a solid-state drive.

[0151] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0152] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0153] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0154] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0155] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0156] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, 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 network device, etc.) 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 program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0157] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0158] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for sharing health data based on the Internet of Things, characterized in that, Includes the following steps: S1. Collect raw health data continuously uploaded by IoT terminals and generate corresponding raw authorization identifiers according to data source, collection time sequence and user authorization content; S2. Based on the original authorization identifier, parse the authorization boundary of the original health data and construct a constraint mapping chain containing data nodes, authorization nodes and time nodes; S3. Perform risk scoring on the raw health data and record the derivation path between the raw health data and the derived health data according to the processing procedure. S4. Based on the derived path, the constraint mapping chain is synchronously transmitted to the derived health data, and the inheritance authorization identifier of the corresponding derived health data is generated. S5. After receiving the user's authorization change instruction, retrieve the corresponding derived health data and real-time access time according to the inherited authorization identifier, and reconstruct the authorization boundary of the corresponding constraint mapping chain. S6. Based on the reconstructed authorization boundary, perform access verification on the derived health data and map the verification results to the shared control results.

2. The method for sharing health data based on the Internet of Things according to claim 1, characterized in that, S1, specifically: Collect raw health data continuously uploaded by IoT terminals; Extract the data source identifier and collection time sequence marker carried in the raw health data; Obtain user-authorized content related to the original health data sharing object that is pre-set by the user within the time range corresponding to the collection time sequence marker; The data source identifier, collection time sequence marker, and user authorization content are associated to generate a unique original authorization identifier corresponding to the original health data.

3. The method for sharing health data based on the Internet of Things according to claim 2, characterized in that, S2, specifically: Determine the authorization boundaries corresponding to the original health data based on the user-authorized content; Extract the data source identifier and collection time sequence marker corresponding to the original health data; Map the data source identifier to a data node in the constraint mapping chain; Map the acquisition time sequence markers to time nodes in the constraint mapping chain; Map the authorization boundaries corresponding to the user-authorized content to authorization nodes in the constraint mapping chain; Associate data nodes, authorization nodes, and time nodes to construct a constraint mapping chain corresponding to the original health data.

4. The method for sharing health data based on the Internet of Things according to claim 3, characterized in that, S3, specifically: Extract the original health data within the data source boundary corresponding to the data node in the constraint mapping chain; The extracted raw health data is processed with risk scoring to generate derived health data; Record the start and end times of risk scoring, the processing type identifier, and the original health data fragments called during the processing. Write the start and end times of the processing, the processing type identifier, the original health data fragments, and the generated derived health data into the derived path record.

5. A method for sharing health data based on the Internet of Things according to claim 4, characterized in that, S4, specifically: Extract the generated derived health data and the corresponding original health data fragments from the derived path records; Locate the data nodes, authorization nodes, and time nodes that correspond to the original health data segments in the constraint mapping chain; Extract the data source boundary corresponding to the located data node, the shared object boundary corresponding to the authorized node, and the time boundary corresponding to the time node into an authorized boundary constraint set; Generate an inheritance authorization identifier that uniquely corresponds to the derived health data, and write the set of authorization boundary constraints into the inheritance authorization identifier.

6. A method for sharing health data based on the Internet of Things according to claim 5, characterized in that, S5, specifically: Receive user authorization change instructions and extract the changed user authorization content from the user authorization change instructions; Traverse the inheritance authorization identifiers that are bound to the derived health data in the derived path record; Extract the authorization boundary constraint set from the inherited authorization identifier. The authorization boundary constraint set includes the data source boundary, the shared object boundary, and the time boundary. The modified user authorization content is compared with the set of authorization boundary constraints to determine the boundaries of shared objects affected by the user authorization change instruction; Locate the authorization node corresponding to the boundary of the affected shared object in the constraint mapping chain; Update the shared object boundaries corresponding to the authorized node based on the changed user authorization content; The updated shared object boundaries are rewritten into the set of authorization boundary constraints that inherit the authorization identifier.

7. A method for sharing health data based on the Internet of Things according to claim 6, characterized in that, S6, specifically: Obtain access requests to derived health data, and extract the request initiator identifier and request access time from the access requests; Locate the inheritance authorization identifier corresponding to the derived health data in the derived path record; Extract the authorization boundary constraint set from the inherited authorization identifier. The authorization boundary constraint set includes the data source boundary, the shared object boundary of the shared object after writing and updating, and the time boundary. The request initiator's identifier is matched and verified against the shared object boundary, and the request access time is verified against the time boundary. When the request initiator's identifier matches the shared object boundary and the request access time is within the time boundary, a shared control result allowing access to derived health data is generated. When the request initiator's identifier does not conform to the shared object boundary or the request access time exceeds the time boundary, a sharing control result of denying access to derived health data is generated.

8. A health data sharing system based on the Internet of Things (IoT), used to implement the health data sharing method based on the Internet of Things as described in any one of claims 1-7, characterized in that, include: Original Authorization Module: Collects raw health data continuously uploaded by IoT terminals and generates corresponding original authorization identifiers according to data source, collection time sequence and user authorization content; Mapping Module: Based on the original authorization identifier, the authorization boundary of the original health data is parsed, and a constraint mapping chain containing data nodes, authorization nodes, and time nodes is constructed. Inheritance authorization module: performs risk scoring on the original health data and records the derivation path between the original health data and derived health data according to the processing procedure; Path recording module: Based on the derived path, the constraint mapping chain is synchronously transmitted to the derived health data, and the inheritance authorization identifier of the corresponding derived health data is generated; Boundary Reconstruction Module: After receiving the user's authorization change instruction, it retrieves the corresponding derived health data and real-time access time according to the inherited authorization identifier, and reconstructs the authorization boundary of the corresponding constraint mapping chain; Access verification module: Based on the reconstructed authorization boundary, it performs access verification on derived health data and maps the verification results to the shared control results.

Images