Vision health data management and privacy protection method based on block chain

Abstract

The invention provides an eyesight health data management and privacy protection method based on a block chain, and the method comprises the steps: verifying the role identity of a requester through an intelligent contract if a query request is detected in an encrypted archive structure, judging whether the role identity accords with a preset hierarchical authorization rule or not, and obtaining an authorization verification result; after the filtered data response is obtained, generating a hash value of query operation by adopting an encryption algorithm, and determining a unique identifier of the access so as to facilitate subsequent tracking; broadcasting the generated hash value and access details to all nodes of the block chain network through a consensus algorithm, judging whether the network is consistent or not, and obtaining a confirmed log recording block; historical access behaviors are retrieved from the confirmed log record blocks, if an abnormal access mode is found, an alarm mechanism is triggered, and a complete traceable audit path is obtained to maintain data privacy.

Description

Technical Field

[0001] This invention relates to the field of information technology, and in particular to a blockchain-based method for vision health data management and privacy protection. Background Technology

[0002] The vision health of teenagers is receiving increasing attention, especially given the continued rise in myopia rates. Establishing a safe, continuous, and reliable vision health record system is of paramount importance.

[0003] This system not only needs to record vision data throughout the entire lifecycle from kindergarten to high school, but also needs to ensure that families, schools, and medical institutions can securely share information to support scientific vision intervention and health management.

[0004] The distributed storage and immutability of blockchain technology offer new possibilities for this need, but how to achieve secure data sharing and access control in complex scenarios involving multiple parties has become a research area that urgently needs to be addressed.

[0005] Currently, many vision health record systems rely on centralized databases, which are convenient for management but have problems such as data tampering, leakage, and difficulty in finely controlling access permissions.

[0006] Traditional systems typically manage data access through a unified permission allocation mechanism, but this approach is difficult to adapt to the diverse data access needs of different roles such as parents, schools, and medical institutions.

[0007] For example, parents need to see their child's detailed vision records, while schools only need overall statistics for the class, and medical institutions may need specific examination details for individual students.

[0008] Existing methods often fail to flexibly meet these diverse needs while ensuring data security, resulting in inefficient information sharing or the risk of unauthorized access.

[0009] In a vision health record system supported by blockchain technology, the core technical challenge lies in how to achieve hierarchical query authorization and data access security.

[0010] Hierarchical query authorization requires the system to accurately allocate access permissions according to the needs of different roles, ensuring that each role can only access data related to its responsibilities.

[0011] However, such precise permission allocation needs to be implemented on the blockchain through smart contracts, and the design of smart contracts needs to ensure efficient execution and data privacy in a distributed environment.

[0012] This leads to another technical challenge: how to generate immutable log records for each query in order to track access behavior and prevent unauthorized access.

[0013] Log generation needs to ensure both system performance and the traceability of all operations.

[0014] For example, a school teacher may need to access vision screening statistics for students in their class. However, if the system cannot accurately distinguish the teacher's access permissions, the teacher may accidentally access a student's detailed refractive error data, thereby raising the risk of privacy breach.

[0015] Therefore, how to implement hierarchical query authorization through smart contracts on the blockchain, while ensuring that each query generates an immutable log record to meet the differentiated needs of multiple parties and protect data privacy, has become a key issue for vision health record management systems. Summary of the Invention

[0016] This invention provides a blockchain-based method for vision health data management and privacy protection, mainly including:

[0017] Vision data is obtained from multiple participating nodes through a consensus algorithm and stored on the blockchain to obtain an initial vision health record block, which contains records from kindergarten to high school to support subsequent sharing. Based on the obtained vision health record blocks, the data is encrypted using an encryption algorithm to perform hierarchical encryption processing, and the specific access permissions of different roles such as parents, schools and medical institutions are determined, thereby generating an encrypted record structure. If a query request is detected in the encrypted file structure, the role and identity of the requester are verified through the smart contract to determine whether it meets the preset hierarchical authorization rules and obtain the authorization verification result. Extract the allowed data subset from the authorization verification results, provide only class statistics for school roles, and provide detailed examination details for medical institutions, resulting in a filtered data response; After obtaining the filtered data response, an encryption algorithm is used to generate a hash value for the query operation, which determines the unique identifier of this access for subsequent tracking; The generated hash value and access details are broadcast to all nodes of the blockchain network through a consensus algorithm to determine whether the network has reached a consensus and obtain a confirmed log record block. Historical access behavior is retrieved from confirmed log records. If abnormal access patterns are found, an alarm mechanism is triggered to obtain a complete traceable audit path to maintain data privacy.

[0018] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects:

[0019] This invention discloses a blockchain-based method for vision health data management and privacy protection. Addressing the business needs of secure storage, hierarchical access control, and traceable auditing of vision data in multi-party scenarios, it solves the privacy protection and access control issues in data sharing. This invention collects vision data from multiple nodes from kindergarten to high school using a consensus algorithm, generating initial health profile blocks. The data is then encrypted using a hierarchical encryption algorithm, and access permissions are set based on roles such as parents, schools, and medical institutions. A smart contract verifies the identity of the query requester and generates authorization results according to preset rules, providing only class statistics to schools and detailed examination information to medical institutions. Each query operation generates a hash value as a unique identifier, which is broadcast to the blockchain via the consensus algorithm to ensure the consistency and traceability of access logs. When abnormal access patterns are detected, an alarm is triggered and an audit path is provided. This invention, through the integration of blockchain and encryption technology, ensures secure sharing, efficient access, and privacy protection of vision data, significantly improving the transparency and credibility of data management. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating a blockchain-based method for vision health data management and privacy protection according to the present invention. Figure 2 This is a schematic diagram of a blockchain-based method for vision health data management and privacy protection according to the present invention; Figure 3 This is another schematic diagram of a blockchain-based vision health data management and privacy protection method according to the present invention. Detailed Implementation

[0021] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0022] like Figure 1-3 This embodiment of a blockchain-based method for vision health data management and privacy protection may specifically include:

[0023] Step S101: Obtain vision data from multiple participating nodes through a consensus algorithm and store it on the blockchain to obtain an initial vision health record block, which contains records from kindergarten to high school to support subsequent sharing.

[0024] Specifically, vision data is obtained from multiple participating nodes using consensus algorithms such as PBFT (Practical Byzantine Fault Tolerance) or its variants (such as Raft), data consistency is verified, and an initial vision dataset is generated. If the data verification passes, the initial vision dataset is stored on the blockchain, generating a vision health record block containing a timestamp. The participating nodes mainly include: medical institution nodes, educational institution nodes (schools), regulatory / health administration departments, and technical service nodes. Data consistency verification is achieved through hash anchoring and distributed voting. After data entry, the system does not broadcast the original vision data across the entire network (to protect privacy). Instead, it calculates the hash value of the dataset using the SHA-256 algorithm. Even a single byte change in the original data will result in a completely different hash value. The master node (such as the hospital node currently responsible for accounting) encapsulates this hash value and timestamp into a proposal and broadcasts it to all other participating nodes. Upon receiving the proposal, each node compares the hash value generated from the locally received data (or data obtained through an encrypted channel) with the broadcast hash value. If they match, the node signs an agreement response. When more than two-thirds of the nodes in the network (a preset threshold) reach a consensus, the system considers the data consistent and generates a definitive log block. At this point, the hash fingerprint of the data is permanently anchored to the blockchain. If any party subsequently tampers with the local data, the verification will fail because the hash value will not match.

[0025] Furthermore, based on the vision health record blocks stored on the blockchain, vision data from kindergarten to high school is extracted to construct a structured record. Using this structured record and distributed query technology, vision data at each stage is retrieved to determine vision change trends. If the vision change trend exceeds a preset threshold, K-means clustering in machine learning algorithms is used to classify vision health status and obtain health status labels. Based on these health status labels, data encryption technologies such as standard PGP / GPG patterns are used to generate shared encrypted vision records, which are then stored on the blockchain. Through the blockchain's distributed ledger technology, the encrypted vision records are retrieved, sharing permissions are verified, and shareable vision health data is output.

[0026] In one possible implementation, a complete structured archive is presented internally by the system with the following logical structure:

[0027] Basic index layer: unique user identifier + full-cycle timestamp.

[0028] Data content layer: personal basic information + refractive error / visual acuity test values ​​+ medical advice text.

[0029] Intelligent analysis layer: Vision change trend value + health status label (such as "high risk", "stable" etc.).

[0030] Access protection layer: hierarchical encryption identifiers (corresponding to access permissions for different roles).

[0031] In this way, the archives not only achieve logical order of data, but also possess traceability, privacy protection capabilities, and decision support functions.

[0032] In one possible implementation, the process of acquiring vision data at various stages and determining vision change trends through structured archives and distributed query technology, within the context of blockchain, refers to a distributed data retrieval mechanism based on blockchain nodes, specifically employing on-chain indexing and multi-node data aggregation. The on-chain indexing refers to the mapping table established by the smart contract when storing data, based on the user's unique identifier and educational stage label (kindergarten / primary / middle / high school). The multi-node data aggregation addresses the issue of vision data being scattered across blocks at different times or nodes in different institutions. The system uses SQL-on-Blockchain technology, which does not alter the underlying chain structure but instead initiates query requests to multiple participating nodes simultaneously through a single logical layer, aggregating fragmented data into a complete time series in real time.

[0033] After obtaining time-series data sorted by time through distributed querying, the system determines the trend through the following three steps: First, data standardization and cleaning: Vision data from different periods may have different formats (e.g., some records show a visual acuity of 5.0, while others show a refractive error of -1.50D). The system first transforms this heterogeneous data into a unified structured feature vector. Second, trend calculation model (specific algorithm): Linear / nonlinear regression analysis: Using time as the x-axis and visual acuity indicators (e.g., myopia degree) as the y-axis, a regression curve is calculated. The slope β of the curve represents the rate of visual acuity decline. Sliding window rate of change: Calculate the change value between two adjacent physical examination cycles. .For example: K-means clustering analysis: The student's vision change characteristics (such as the rate of decline, the amount of astigmatism increase, etc.) are input into the clustering algorithm and categorized into preset health patterns: stable (curve slope close to 0), warning (slope exceeds a preset threshold, such as: myopia increase of more than 50 degrees within one year), and high-risk (the change curve shows an exponentially accelerating decline). The third step is trend result output: The final generated trend is not just a vague description like "declined," but is converted into structured labels stored in the archive, for example: {"trend":"Rapid_Declining","risk_score":0.85,"prediction":"-2.0D_at_Grade 9"}.

[0034] In one possible implementation, the system utilizes blockchain's distributed ledger technology to obtain encrypted vision records, verify sharing permissions, and output shareable vision health data. This distributed ledger technology is a decentralized storage mechanism that is jointly maintained by multiple parties and is tamper-proof. The verification of sharing permissions is automatically executed through smart contracts and tiered authorization rules. The specific process is as follows: Step 1: When a query request is initiated, the system first obtains the requester's role identifiers: parent, school, and medical institution. Step 2: The system calls a smart contract pre-deployed on the blockchain to automatically retrieve the permission scope of this role in the tiered authorization table. It determines whether the current requester's ID is on the list of those allowed to access the specific record. If the request is from a medical institution, it checks whether the institution has a medical practice license. Step 3: If the verification result is a school, the smart contract executes filtering rules, extracting only class statistics (generating the first data subset). If the verification result is a medical institution, detailed clinical data such as refractive error is extracted (generating the second data subset). Step 4: Outputting shareable data. Finally, the system uses JSON formatting to generate a structured response and encrypts it again using the AES algorithm to ensure that the data is not eavesdropped on by third parties during transmission to the requester.

[0035] Step S102: Based on the obtained vision health record block, the data is encrypted using an encryption algorithm to perform hierarchical encryption processing, and the specific access permissions of different roles such as parents, schools and medical institutions are determined, thereby generating the encrypted record structure.

[0036] The process involves acquiring vision health record data, parsing the data structure, and extracting content including personal information, vision examination records, and medical recommendations to obtain a structured data set. A symmetric encryption algorithm, such as AES, is used to initially encrypt the structured data set, generating a first encrypted data set. Based on parental roles and permissions, the portion of the first encrypted data set related to student vision examination records is extracted, and access permissions are assigned to parents using access control lists, resulting in a parent-access data subset. Based on school roles and permissions, the portion of the first encrypted data set related to student group vision statistics is extracted, and access permissions are assigned to schools using access control lists, resulting in a school-access data subset. Based on medical institution permissions, the portion of the first encrypted data set related to medical recommendations and diagnostic records is extracted, and access permissions are assigned to medical institutions using access control lists, resulting in a medical institution-access data subset. Asymmetric encryption algorithms, such as RSA, are then used to further encrypt the parent-access data subset, school-access data subset, and medical institution-access data subset, generating the final encrypted file structure. The access control mechanism verifies the access requests of each role. If the request meets the preset permission range, the corresponding permission data subset is decrypted to obtain the authorized access data. The access control mechanism is a combination of attribute access control or role access control based on blockchain and is automatically executed in conjunction with smart contracts.

[0037] Step S103: If a query request is detected in the encrypted file structure, the role and identity of the requester are verified through the smart contract to determine whether it meets the preset hierarchical authorization rules and obtain the authorization verification result.

[0038] If a query request is detected in the encrypted file, the request content is parsed to obtain the requester's identifier and the request target, resulting in structured request data. A pre-defined hierarchical authorization rule is loaded via a smart contract, and the requester's role identity is extracted from the structured request data to obtain role identity information. Based on the role identity information and permission rules, identity verification is performed to determine if the authorization conditions are met, resulting in a permission matching result. If the permission matching result is successful, the target data is extracted from the encrypted file, processed using a decryption algorithm, and the decrypted file content is obtained. Based on the decrypted file content, a response data packet is generated, with a verification result identifier appended, resulting in a formatted query response. The formatted query response is transmitted through the blockchain network, a transmission log is recorded, and a transmission confirmation message is obtained. Based on the transmission confirmation message, the smart contract state is updated, the query record is stored, and the final business processing result is obtained.

[0039] In one possible implementation, the step of loading a preset hierarchical authorization rule through a smart contract to extract the requester's role identity from structured request data and obtain role identity information involves a set of role-based data access control (RBAC) rules, which are either hard-coded or stored in the smart contract. The specific rules are as follows:

[0040] Data visibility classification: The rules divide visual data into statistical level and detailed level.

[0041] Role and Permission Mapping: School Role: Rules define its permissions as limited to class statistics (e.g., class myopia rate, number of students with passing vision tests), prohibiting access to students' personal information and detailed prescription details. Medical Institution: Rules define its permissions as detailed examination information (e.g., refractive error, axial length, clinical diagnostic recommendations) to support precision medicine. Parent Role: Rules define its permissions as personal full-cycle records, limited to accessing the complete files of their associated children.

[0042] When the system detects a query request in the encrypted archive structure, the smart contract is automatically activated. The contract automatically loads the pre-defined logic code (i.e., authorization rules) from the blockchain's storage layer and applies it to the current request context (such as the requester's signature and ID). The entire process requires no manual intervention, ensuring the objectivity and real-time nature of the authorization.

[0043] In one possible implementation, the process of performing identity verification based on role identity information and permission rules to determine whether authorization conditions are met and obtain permission matching results involves a dual verification process of identity and permission scope. The first layer is identity legitimacy verification (Who are you?), which determines whether the digital certificate or ID provided by the requester belongs to a registered parent, school, or medical institution. If no such person is found in the identity database, it is directly determined as non-compliant. The second layer is access scope verification (What can you see?), even if the identity is legitimate, the system still needs to determine whether the content requested for access is within the scope of your role's authorization. Example: A school teacher (legitimate identity) requests to view a student's detailed medical records. The smart contract, by comparing the hierarchical authorization rules, finds that the school role can only view statistical data, therefore determining that the request does not meet the authorization conditions. Only when the identity is legitimate and the requested content matches the role's permission level will a positive permission matching result be obtained, thereby achieving secure distribution of files.

[0044] Step S104: Extract the allowed data subset from the authorization verification result. Provide only class statistics for school roles, and provide detailed examination details for medical institutions. Use preset data filtering rules to obtain the filtered data response.

[0045] Specifically, the user role identifier and data access permissions are obtained from the authorization verification results to determine the role type. If the role type is a school role, class statistics are extracted from the allowed access data to generate a first data subset. If the role type is a medical institution, detailed examination data is extracted from the allowed access data to generate a second data subset. Based on either the first or second data subset, a preset data filtering rule is applied to obtain a filtered data set. The preset data filtering rule is a data trimming algorithm based on the minimum necessary data principle. It determines the role type according to S103, performs a secondary cleaning of the original data subset, and removes sensitive fields unrelated to the role. The specific rules are as follows:

[0046] Filtering rules (anonymization rules) for school roles: Identity anonymization: Automatically removes students' names, ID numbers, home addresses, contact numbers, and other personal privacy fields. Numerical fuzzification: Filters out specific vision values ​​(e.g., left eye 4.8, right eye 4.7), converting them into statistical features (e.g., the student's vision is within the acceptable range). Aggregation processing: Only retains group attributes such as class ID and grade, ensuring that the output results are only macro-level class statistical indicators through filtering rules.

[0047] Filtering rules for medical institutions (professional extraction rules): Non-medical data filtering: Remove information irrelevant to clinical diagnosis, such as student performance and class ranking. Refined extraction: Retain and filter out key parameters required for medical diagnosis, such as refractive error, axial length, corneal curvature, historical prescription records, and medical advice text.

[0048] The preset filtering rules solve secondary security issues after authorization, such as preventing permission overflow: even if the smart contract allows medical access institutions to access, the filtering rules will still ensure that doctors cannot obtain students' home addresses, making the data usable but not visible; generating structured responses: the filtered data set is organized by the rules and encapsulated in JSON format to ensure that different terminals can recognize it.

[0049] Furthermore, by matching the dataset with role types and using JSON formatting, a structured data response is generated. This structured data response is then encrypted using the AES encryption algorithm to obtain an encrypted data response. Based on the encrypted data response, the final data response is generated using a pre-defined transport protocol such as HTTPS or gRPC.

[0050] In one possible implementation, the process of generating the final data response involves encapsulating the AES-encrypted ciphertext in JSON format, adding a timestamp and status tag, and finally sending it to the requester through a secure network channel, based on the encrypted data response. Using the HTTPS security protocol can ensure the security of data transmission.

[0051] Step S105: After obtaining the filtered data response, use an encryption algorithm to generate a hash value for the query operation and determine a unique identifier for this access for subsequent tracking.

[0052] Specifically, the process involves obtaining the filtered data response, cleaning the input data using preset filtering rules to obtain filtered data that meets the criteria, and encrypting the timestamps of the filtered data and query operations using a hash algorithm to generate hash values. The metadata of the query operation and the filtered data are then hashed using the SHA-256 encryption algorithm to obtain a unique identifier. If the generated unique identifier is duplicated with an identifier in an existing tracking log, the hash value is recalculated using the timestamp and a random salt value to obtain a new unique identifier. This unique identifier is then bound to the query record and stored in a preset tracking log database to generate a query tracking record.

[0053] The preset filtering rule is a logical instruction that accurately extracts core audit elements such as "visitor, access object, and access time" from the query response and removes irrelevant and redundant information. Specifically, it includes the following three dimensions: 1. Business Feature Filtering: Extracts core business fields from the data response, such as the user ID involved in this query, the category of vision health indicators (refractive error or statistical report), and the data volume. 2. Security Feature Filtering: Extracts metadata for this access, including: requester role identifier, numeric name, and access source IP or node ID. 3. Redundancy Removal: The rule filters out irrelevant formatting code, padding characters, or redundant comments in the response packet, retaining only the aforementioned core fields to ensure the uniqueness and representativeness of the generated hash value.

[0054] In one possible implementation, the filtered data response is obtained. The filtering rules automatically scan the response packet, simplifying "Zhang San's vision test report" into a set of feature vectors (e.g., {Role: Medical, TargetID:001, Timestamp:1712345678, DataHash: xxxx}). This simplified filtered data serves as input to the next step in S105 (SHA-256 encryption) to generate a unique identifier for this access. Without data cleaning, even minor format differences in the response packet can lead to completely different hash values. Extracting fixed features through filtering rules ensures the comparability of similar query behaviors in the tracking log. Furthermore, the tracking log database does not need to store complete query results (otherwise, storage costs would be extremely high). By extracting features and generating hashes through filtering rules, only a 256-bit hash string needs to be stored, enabling efficient tracking of massive amounts of access behavior.

[0055] In one possible implementation, a logical mapping implemented through hash primary keys binds unique identifiers to query records, which are stored in a pre-defined tracking log database to generate query tracking records. The pre-defined tracking log database is a high-security, audit-enabled distributed storage component. It does not store the vision records themselves, but rather stores access evidence for the records, serving as the core data foundation for privacy protection auditing (step S106, abnormal pattern detection). Specifically, it includes a unique identifier (a 64-bit hexadecimal hash string generated by SHA-256), operation metadata (the visitor's role identifier and digital signature), context information (the specific timestamp of the query, the request source IP address, and the smart contract number invoked), a data digest (filtered data feature values), and a random salt value (a random number used when a hash collision occurs).

[0056] Furthermore, based on the unique identifier in the tracking log database, the data integrity of the query records is periodically verified to determine whether data tampering has occurred. By querying tracking records and unique identifiers, the context information of the operation tracking is extracted to generate an operation sequence log.

[0057] In one possible implementation, the system periodically verifies the data integrity of query records based on unique identifiers in the tracking log database to determine if data tampering has occurred. This integrity verification is performed using an automated mechanism of "timed triggering + hash comparison," such as a preset verification frequency (e.g., every morning or every hour) that automatically starts the verification process. The verification process iterates through each query record in the tracking log database. For each record, the system extracts its original metadata, filtered data, timestamp, and random salt value, and recalculates the hash value using the SHA-256 encryption algorithm defined in S105. The system extracts the unique identifier bound at the time of storage (i.e., the initial hash value at storage) from the database record. The newly generated hash value is then compared bit-by-bit with the unique identifier stored in the database.

[0058] The logic for determining whether data tampering has occurred is based on the collision resistance and avalanche effect of hash algorithms: if the recalculated hash value is completely consistent with the unique identifier stored in the database, it indicates that the query record has not been modified during storage, the data has integrity, and is determined to be tamper-free; if the two are inconsistent, the system immediately determines that the record has been tampered with. Tampering scenario A: An attacker modifies the access time or visitor ID in the log. Since the hash input has changed, the recalculated hash value will inevitably be different. Tampering scenario B: To cover up illegal access, an attacker deletes some audit fields. The verification program may fail to calculate or produce inaccurate results due to missing fields or changes in content.

[0059] The periodic verification is achieved by recalculating the SHA-256 value and comparing it with the original stored identifier. The judgment criteria are: hash value matching = data security; hash value mismatch = risk of tampering. This method utilizes the binding force of cryptography to ensure that every query operation of vision data is traceable and non-repudiable.

[0060] Step S106: Broadcast the generated hash value and access details to all nodes of the blockchain network through a consensus algorithm, determine whether the network has reached a consensus, and obtain the confirmed log record block.

[0061] A hash value is generated from the input data using a pre-defined consensus algorithm, resulting in a unique hash value. This hash value is then broadcast to all network nodes using a distributed network protocol, obtaining a broadcast confirmation status. If the broadcast confirmation status reaches a pre-defined threshold number of nodes, a node verification process is triggered to determine network consistency. Based on the results of the node verification process, feedback data from each node is collected, including verification result identifiers, node digital signatures, and local state roots, to determine data integrity. Log blocks are generated based on the data integrity check results, determining the block generation frequency. If the block generation frequency meets a pre-defined threshold, the log blocks are stored in the blockchain network, obtaining confirmed block data. Furthermore, based on the confirmed block data, the network node status is updated, resulting in a synchronization record for the distributed network.

[0062] The preset consensus algorithm mechanism is a distributed network protocol (such as PBFT) that extracts summaries from audit log data and compares and verifies them among multiple nodes to ultimately achieve automated collaborative rules for data synchronization and confirmation. Specifically, this mechanism obtains the unique identifier (query fingerprint) and access details (who viewed what and when) produced by S105. The algorithm calculates the digest of the unique identifier and access details. Even a slight change in the access details (such as a 1-second time offset) will result in a completely different hash value. The generated hash value is sent to all nodes in the blockchain network (schools, medical institutions, regulatory departments). Each node verifies whether the hash value generation rule is legal and whether the corresponding access behavior conforms to the smart contract record. When the network reaches a consensus (meeting the preset consensus threshold), the hash value is officially written into the ledger, generating an immutable confirmation log record block.

[0063] In one possible implementation, a distributed network protocol is used to broadcast the hash value to all network nodes to obtain a broadcast confirmation status. If the broadcast confirmation status reaches a preset node number threshold, such as more than 2 / 3 of the total number of nodes (i.e., more than 2 / 3n) or more than half (i.e., more than 1 / 2n), a node verification process is triggered, namely: identity signature verification: verifying whether the data packet was sent by a legitimate source node and checking the digital signature; hash matching verification: each node re-runs the same hash algorithm locally to calculate a local hash value based on the received access details raw data, and compares it with the unique hash value received from the broadcast; logical rule verification: verifying whether the query operation conforms to the permission rules defined by the smart contract, such as a node verifying: "The requester's identity is a school teacher, is the requested data indeed the de-identified statistical data?"; double-spending / conflict detection: checking whether there is a logical conflict in the operation (such as duplicate records under the same timestamp).

[0064] Furthermore, the system collects "verification passed / failed" feedback from all participating verification nodes. If more than a preset threshold (e.g., 2 / 3) of the nodes report successful verification, and the state root or hash value calculated by each node is completely consistent, the network is considered to have reached consensus. If the number of nodes reporting "passed" does not reach the threshold, or if the hash values ​​calculated by different nodes diverge (fork), the system determines that the network is inconsistent. In this case, the proposal will be discarded or a new consensus will be triggered to prevent false information from being uploaded to the blockchain. Once consensus is determined, the system will formally package the hash value and access details to generate a confirmed log block, which will be permanently stored in the blockchain ledger.

[0065] In one possible implementation, the generation of log records based on the data integrity check results, to obtain the block generation frequency, refers to the number of log records successfully generated and ready to be uploaded to the blockchain per unit time. Its calculation is typically based on timestamp differences and block counts, using the following formula:

[0066]

[0067] Where N is the total number of log records generated within a specific observation period, and T is the start and end time of that period.

[0068] Specific acquisition process: When a log block passes the data integrity check and completes consensus encapsulation, the system records the block's generation timestamp. The monitoring system counts the number of generated confirmed log blocks within a preset sliding window (e.g., every minute or every 10 minutes). The real-time block generation rate (e.g., 5 blocks / min) is obtained by dividing a counter by the window duration. Step S107: Historical access behavior is retrieved from the confirmed log blocks. If an abnormal access pattern is found, an alarm mechanism is triggered to obtain a complete traceable audit path to maintain data privacy.

[0069] Historical log records are retrieved from the storage system, and access behavior data is extracted using log parsing tools to obtain a structured access behavior dataset. Feature extraction is performed on this structured dataset, and k-means clustering is used to analyze access behavior patterns and identify potential abnormal access patterns. If an abnormal access pattern is detected, an alarm mechanism is triggered based on a preset threshold, generating alarm information containing timestamps and access sources. The preset thresholds are quantitative security indicators set based on behavioral statistics (e.g., cluster distance), access frequency (e.g., number of requests per unit time), and compliance verification (e.g., number of unauthorized attempts). Based on the alarm information, relevant log records are extracted from the access behavior dataset, and a traceable audit path is generated using a hash algorithm to obtain an audit path identifier. The audit path identifier is encrypted using AES encryption to protect privacy data, resulting in an encrypted audit path. Time-series features of access behavior are extracted from the encrypted audit path, and alarm response times are analyzed to determine if there are any delays. Based on the time-series features, access data filtering rules are updated, and subsequent log data analysis is optimized to obtain more accurate anomaly detection results. The log parsing tool is a component with the ability to "unpack, decode, and reconstruct" and consists of a blockchain data extractor, an ABI decoder, and a structured mapping engine. It typically uses tools such as ELK Stack, Hyperledger Explorer, The Graph, Fluentd, and Promtail.

[0070] In one possible implementation, the feature extraction is performed on a structured access behavior dataset, and the k-means clustering algorithm is used to analyze access behavior patterns to identify potential abnormal access patterns. The feature extraction transforms the raw, messy log information into a numerical vector that can be recognized by the machine learning algorithm (K-means), such as: [access frequency, standard deviation of time interval, proportion of sensitive data, number of cross-institutional accesses].

[0071] K-means clustering allows the system to categorize access behaviors. Outliers far from the centers of normal clusters, or behaviors categorized into specific risk clusters, are considered potential anomalous access patterns. These include: High-frequency batch crawling: Initiating query requests to a large number of different students' files within a very short period, with an access frequency far exceeding the limits of normal human operation. This could indicate a hacker attempting to steal vision data from all students in a school or district. Abnormal time period access: Large-scale data retrieval behavior from school or medical institution accounts during non-working hours (e.g., 2 AM to 4 AM). Permission overreach: An account frequently attempts to access data outside its authorized scope (e.g., a school account repeatedly triggers filtering rules in S104, attempting to obtain detailed medical data). Although intercepted by the smart contract, this attempt itself is considered anomalous. Remote concurrent access: The same account appears on two physically distant IP addresses within a very short period, suggesting potential account theft. Mechanical / scripted access: Access at extremely precise intervals (e.g., requests every 1.00 seconds), inconsistent with the random, paused habits of human operation.

[0072] Once the aforementioned abnormal patterns are identified, the system combines the confirmation log blocks generated in S106 to trace the complete context of the behavior (requester ID, access time, and specific original data block) using unique identifiers, generating a complete traceable audit path. Feature extraction involves transforming logs into numerical vectors through standardization and time window aggregation; abnormal patterns are identified through clustering, such as brute-force crawling, unauthorized attempts, hacking, and automated scripts, which deviate from normal behavior. This constitutes the final security barrier for vision health data on the blockchain.

[0073] In one possible implementation, based on the timestamps and access sources contained in the alert information, relevant log records are extracted from the access behavior dataset. These extracted log records are then arranged by timestamp to generate an initial audit sequence. A hash algorithm, such as SHA-256, is applied to this initial audit sequence to generate a unique hash value. This hash value serves as a traceable audit path identifier, ensuring the uniqueness, integrity, and immutability of the audit path for easy post-event verification. Subsequently, the system temporarily freezes the blockchain access key for the role ID and directly writes the abnormal behavior characteristics that triggered the alert into an "immutable log block" as evidence for subsequent law enforcement or management. A real-time alert email or SMS is then sent to the system administrator (such as the education bureau's security director or medical system operations manager).

[0074] In one possible implementation, time-series features of access behavior are extracted from the encrypted audit path, including access frequency, request interval, burstiness (the degree of sudden surge in traffic within a very short period of time), and duration. The alarm response time is analyzed to determine if there are any delays. The alarm response time typically refers to the entire process from when the system detects an anomaly to when intervention measures are taken. Specifically, it includes two parts: detection delay (the time difference between the occurrence of abnormal access behavior and when the system identifies and triggers an alarm) and handling delay (the time difference between when the alarm is triggered and when the system executes automatic interception, such as blocking IPs or locking accounts). Formula: Alarm Response Time = Handling Completion Time - Anomaly Start Time.

[0075] To determine if a delay issue exists, the system monitors the response time in real time and compares it to a safety baseline. If the measured response time... (Preset response time threshold) The system determines that there is a delay issue. The threshold is usually set according to the security level (SLA): Real-time interception level (milliseconds): For known high-risk malicious features (such as brute-force crawling), the threshold is usually set between 500ms and 2s. Audit and verification level (seconds): For complex K-means clustering analysis, due to the large computational cost, the threshold is usually between 5s and 15s.

[0076] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A blockchain-based method for vision health data management and privacy protection, characterized in that, The method includes: Vision data is obtained from multiple participating nodes through a consensus algorithm and stored on the blockchain to obtain an initial vision health record block, which contains records from kindergarten to high school to support subsequent sharing. Based on the obtained vision health record blocks, the data is encrypted using an encryption algorithm to perform hierarchical encryption processing, and the specific access permissions of different roles such as parents, schools and medical institutions are determined, thereby generating an encrypted record structure. If a query request is detected in the encrypted file structure, the role and identity of the requester are verified through the smart contract to determine whether it meets the preset hierarchical authorization rules and obtain the authorization verification result. Extract the allowed data subset from the authorization verification results, provide only class statistics for school roles, and provide detailed examination details for medical institutions, resulting in a filtered data response; After obtaining the filtered data response, an encryption algorithm is used to generate a hash value for the query operation, which determines the unique identifier of this access for subsequent tracking; The generated hash value and access details are broadcast to all nodes of the blockchain network through a consensus algorithm to determine whether the network has reached a consensus and obtain a confirmed log record block. Historical access behavior is retrieved from confirmed log records. If abnormal access patterns are found, an alarm mechanism is triggered to obtain a complete traceable audit path to maintain data privacy.

2. The method for managing and protecting vision health data based on blockchain according to claim 1, characterized in that, The process involves acquiring vision data from multiple participating nodes using a consensus algorithm and storing it on the blockchain to obtain an initial vision health record block. This block contains records from kindergarten to high school to support subsequent sharing and also includes: Based on the vision health record blocks stored on the blockchain, extract vision data from kindergarten to high school and construct structured records; By using structured archives and distributed query technology, vision data at each stage can be obtained to determine the trend of vision changes. If the trend of visual acuity changes exceeds a preset threshold, the visual health status is classified by K-means clustering in the machine learning algorithm to obtain a health status label. Based on health status tags, encrypted vision profiles that can be shared are generated using data encryption technology and stored on the blockchain; By leveraging blockchain's distributed ledger technology, encrypted vision records can be obtained, sharing permissions can be verified, and shareable vision health data can be output.

3. The method for managing and protecting vision health data based on blockchain according to claim 1, characterized in that, The process involves using an encryption algorithm to perform hierarchical encryption on the acquired vision health record blocks, determining the specific access permissions for different roles such as parents, schools, and medical institutions, thereby generating an encrypted record structure, including: We acquire vision health record data, analyze the data structure, and extract the record content, which includes personal information, vision examination records, and medical advice, to obtain a structured data set. A symmetric encryption algorithm is used to perform preliminary encryption on the structured data set to generate the first encrypted data set; Based on parental role permissions, extract the portion of the data related to the student's vision test records from the first encrypted data set, and assign parental access permissions through an access control list to obtain a subset of parental permission data; Based on the school's role permissions, extract the portion of the first encrypted data set related to the vision statistics of the student group, and assign school access permissions through an access control list to obtain a subset of school permission data; Based on the medical institution's permissions, extract the portion of the data related to medical advice and diagnostic records from the first encrypted data set, and assign access permissions to the medical institution through an access control list to obtain a subset of the medical institution's permission data; Asymmetric encryption algorithms are used to perform secondary encryption on subsets of parental permission data, school permission data, and medical institution permission data to generate the final encrypted file structure; The access control mechanism verifies the access requests of each role. If the request conforms to the preset permission range, the corresponding permission data subset is decrypted to obtain the authorized access data.

4. The method for managing and protecting vision health data based on blockchain according to claim 1, characterized in that, If a query request is detected in the encrypted file structure, the requester's role and identity are verified through a smart contract to determine whether it conforms to the preset hierarchical authorization rules and obtain the authorization verification result, including: If a query request is detected in the encrypted file, the request content is parsed to obtain the requester's identifier and the request target, thus obtaining structured request data; By loading preset hierarchical authorization rules through smart contracts, the role identity of the requester can be extracted from the structured request data to obtain role identity information; Based on the role identity information and permission rules, perform identity verification to determine whether the authorization conditions are met and obtain the permission matching result; If the permission matching result is successful, the target data is extracted from the encrypted file, processed by the decryption algorithm, and the decrypted file content is obtained. Based on the decrypted file content, a response data packet is generated, a verification result identifier is attached, and a formatted query response is obtained; The system transmits formatted query responses through a blockchain network, records transmission logs, and obtains transmission confirmation information. Based on the transmission confirmation information, the smart contract state is updated, the query records are stored, and the final business processing result is obtained.

5. The method for managing and protecting vision health data based on blockchain according to claim 1, characterized in that, The process of extracting the allowed data subset from the authorization verification results, providing only class statistics for school roles and detailed examination information for medical institutions, and obtaining a filtered data response, also includes: Obtain the user role identifier and data access permissions from the authorization verification results to determine the role type; if the role type is a school role, extract class statistics from the allowed access data to generate the first data subset; If the role type is a medical institution, then extract detailed examination data from the allowed access data to generate a second data subset; Based on the first or second data subset, a preset data filtering rule is used to obtain the filtered data set. By matching the dataset with the role type and using JSON formatting, a structured data response is generated. Obtain the structured data response, encrypt the data using the AES encryption algorithm, and obtain the encrypted data response; Based on the encrypted data response, the final data response is generated using a preset transmission protocol.

6. The method for managing and protecting vision health data based on blockchain according to claim 1, characterized in that, After obtaining the filtered data response, an encryption algorithm is used to generate a hash value for the query operation, determining a unique identifier for this access for subsequent tracking, including: Obtain the filtered data response, clean the input data using preset filtering rules, and obtain filtered data that meets the conditions; The timestamps of the filtered data and query operations are encrypted using a hash algorithm to generate hash values; The SHA-256 encryption algorithm is used to perform hash calculations on the metadata and filter data of the query operation to obtain a unique identifier; If the generated unique identifier is the same as the identifier in the existing tracking log, the hash value is recalculated using the timestamp and random salt value to obtain a new unique identifier; The unique identifier is bound to the query record and stored in the preset tracking log database to generate the query tracking record.

7. A blockchain-based method for vision health data management and privacy protection according to claim 1, characterized in that, The process of broadcasting the generated hash value and access details to all nodes of the blockchain network through a consensus algorithm, determining whether the network has reached a consensus, and obtaining a confirmed log record block includes: A unique hash value is obtained by generating a hash value from the input data through a pre-defined consensus algorithm mechanism. A distributed network protocol is used to broadcast the hash value to all network nodes and obtain broadcast confirmation status. If the broadcast confirmation status reaches a preset threshold of the number of nodes, the node verification process is triggered to determine network consistency. Based on the results of the node verification process, collect feedback data from each node to determine data integrity. Based on the results of the data integrity check, log records are generated to obtain the block generation frequency. If the block generation frequency meets the preset threshold, the log record block will be stored in the blockchain network and the confirmed block data will be obtained. Based on the confirmed block data, the network node status is updated to obtain the synchronization record of the distributed network.

8. The method for managing and protecting vision health data based on blockchain according to claim 1, characterized in that, The process of retrieving historical access behavior from confirmed log records and triggering an alarm mechanism if abnormal access patterns are found, thereby obtaining a complete traceable audit path to maintain data privacy, includes: Historical log records are retrieved from the storage system, and access behavior data is extracted using log parsing tools to obtain a structured access behavior dataset. By extracting features from a structured access behavior dataset, and using the k-means clustering algorithm to analyze access behavior patterns, potential abnormal access patterns are identified. If an abnormal access pattern is detected, an alarm mechanism is triggered based on a preset threshold to generate alarm information that includes a timestamp and the source of the access. Based on the alarm information, relevant log records are extracted from the access behavior dataset, and a traceable audit path is generated using a hash algorithm to obtain the audit path identifier; By encrypting the audit path identifier and using the AES encryption algorithm to protect privacy data, an encrypted audit path is obtained. Extract time-series features of access behavior from the encrypted audit path, analyze alarm response time, and determine if there are delay issues; Based on time series characteristics, update the access data filtering rules, optimize subsequent log data analysis, and obtain more accurate anomaly detection results.

Images