A blockchain-based medical data access behavior auditing and unauthorized access detection method and system

Abstract

This invention relates to the field of medical information security technology, and discloses a blockchain-based method and system for auditing and detecting unauthorized access to medical data. The method includes: structurally modeling medical data access behavior to construct access behavior feature vectors; performing multi-source fusion risk assessment based on an access control policy model and a behavior learning model to obtain a comprehensive risk value; executing a graded processing strategy according to the risk level and generating corresponding audit logs; structurally organizing the audit logs and constructing a Merkle tree to generate data fingerprints; writing the data fingerprints and summary information into the main chain, storing the complete audit logs in a side chain or off-chain storage, and achieving consistency verification through Merkle proofs; using smart contracts to verify the audit data and automatically execute access control responses, while simultaneously feeding back the audit results for model updates. This invention enables real-time detection, graded processing, and trusted auditing of medical data access behavior.

Description

Technical Field

[0001] This invention relates to the field of medical information security and data auditing technology, and in particular to a blockchain-based method and system for auditing medical data access behavior and detecting unauthorized access. Background Technology

[0002] With the continuous development of medical information systems, various medical data systems such as Hospital Information Systems (HIS), Electronic Medical Records (EMR), and Picture Archiving and Communication Systems (PACS) are widely used, and the sharing and circulation of medical data are becoming increasingly frequent. Against this backdrop, how to effectively audit access to medical data and promptly detect unauthorized access has become a crucial technical issue in ensuring medical data security.

[0003] In existing technologies, medical data access auditing typically employs a centralized logging approach, where a single server or database records and manages access behavior. While this approach is simple in structure and low in implementation cost, it suffers from the following problems: Firstly, centrally stored audit logs are susceptible to tampering or deletion, making it difficult to guarantee the authenticity and integrity of the audit data. Secondly, log recording is primarily used for post-event tracing, lacking real-time analysis capabilities for access behavior and making it difficult to promptly detect unauthorized access.

[0004] To address the aforementioned issues, some existing technologies introduce rule-based access control mechanisms, such as role-based access control (RBAC) or attribute-based access control (ABAC), which constrain access behavior through preset permission policies. However, such technical solutions typically rely on static rule configurations, have limited adaptability to complex dynamic scenarios, and struggle to identify abnormal access behaviors occurring within the scope of legitimate permissions, especially covert internal unauthorized access behaviors.

[0005] Furthermore, with the development of blockchain technology, some technical solutions have attempted to apply blockchain to audit log storage, aiming to enhance the credibility of audit data through the immutability of blockchain. However, such solutions typically upload the entire audit log directly to the blockchain, resulting in high storage pressure and low processing efficiency, making them unsuitable for high-frequency access scenarios in medical systems. Simultaneously, these solutions often focus on data storage itself, lacking a collaborative design with real-time unauthorized access detection mechanisms. Consequently, blockchain is merely used as a post-event evidence storage tool, failing to leverage its collaborative role in the audit process.

[0006] On the other hand, some technical solutions introduce machine learning or anomaly detection algorithms to analyze access behavior in order to improve the intelligence level of unauthorized access detection. However, such solutions usually operate independently of the access control system, fail to form an effective linkage with permission policies, and their detection results are often not coupled with audit and evidence storage mechanisms, making it difficult to reliably record and verify the detection results.

[0007] Furthermore, in data sharing scenarios involving multiple medical institutions, existing technologies still face difficulties in cross-institutional auditing. The lack of a unified audit data structure and trusted sharing mechanism among different institutions makes it difficult to achieve globally consistent auditing and traceability of access behavior.

[0008] Furthermore, data privacy protection needs must be considered during the medical data auditing process. Existing technologies typically protect sensitive information through data encryption, but audit verification often requires access to the raw data, which increases the risk of privacy breaches and makes it difficult to achieve a balance between privacy protection and audit effectiveness.

[0009] In summary, the existing technology has at least the following technical problems: (1) Audit logs are easily tampered with and lack a reliable evidence preservation mechanism; (2) The detection of unauthorized behavior is delayed and lacks real-time capability; (3) Access control and anomaly detection are independent of each other and lack a coordination mechanism; (4) Blockchain applications suffer from storage efficiency and performance bottlenecks; (5) Insufficient cross-agency audit capabilities; (6) Privacy protection and audit verification are difficult to balance.

[0010] Therefore, how to construct a medical data access auditing technology solution that can achieve real-time unauthorized access detection and tamper-proof audit evidence storage in a coordinated manner, while taking into account system performance, cross-institutional collaboration and privacy protection, has become an urgent technical problem to be solved in this field. Summary of the Invention

[0011] In view of this, the purpose of this invention is to provide a blockchain-based method and system for auditing and detecting unauthorized access to medical data, in order to solve the problems existing in the medical data access auditing process, such as the ease with which audit data can be tampered with, the lag in detecting unauthorized behavior, the independence of access control and audit evidence storage, and the difficulty in balancing system performance and data security, thereby realizing real-time detection, hierarchical processing, and reliable evidence storage of medical data access behavior.

[0012] To achieve the above objectives, the present invention provides the following technical solution: In one embodiment of the present invention, a method for auditing and detecting unauthorized access to medical data based on blockchain is provided, comprising the following steps: S1: Structured modeling of access behavior: Collect data access requests from the medical information system and extract access subject identifier, data identifier, operation type, time information and context information to construct a multi-dimensional access behavior feature vector; S2: Multi-source fusion risk assessment: Input the access behavior feature vector into the access control policy model and the behavior learning model to obtain the policy judgment result and behavior anomaly score respectively, and generate a comprehensive risk value based on the preset fusion function; S3: Risk-driven tiered processing mechanism: Based on the comprehensive risk value, risk levels are divided, where: high-risk access triggers real-time blocking and immediate audit log generation; medium-risk access triggers approval or alarm; low-risk access is allowed to execute and enters the batch audit process. S4: Hierarchical Log Construction and Fingerprint Generation: Generate structured audit logs for the access behavior and its risk results, and construct Merkle trees in real-time or batch mode according to the risk level to generate corresponding log data fingerprints; S5: Main chain-side chain collaborative evidence storage: Write the data fingerprint and summary information into the main chain, store the complete audit log in the side chain or off-chain storage, and realize the consistency verification of main chain and side chain data through Merkel proof; S6: Smart contract-based linkage verification and response: The audit data is verified using blockchain smart contracts, and access control response strategies are automatically executed according to the risk level. At the same time, the verification results are fed back to the behavior learning model for dynamic updates.

[0013] Furthermore, the access behavior feature vector includes at least three of the following: user identity attributes, data sensitivity level, access frequency, time distribution characteristics, and environmental security parameters.

[0014] Furthermore, the behavior learning model includes: a time-series-based behavior prediction model and a relationship graph-based behavior association model, used to calculate the time-series anomaly score and the structural anomaly score, respectively.

[0015] Furthermore, the fusion function is a dynamic weighting function, and its weights are adaptively adjusted according to the access scenario and historical false alarm rate.

[0016] Furthermore, the Merkle tree construction process includes: performing hash calculations on multiple audit logs within a preset time window and combining them in pairs to generate parent node hashes until a unique Merkle root is generated.

[0017] Furthermore, the main chain is used to store Merkle root and index information, and the side chain or off-chain storage is used to store complete audit log data, and Merkle proof is used to verify the consistency of data between the main chain and the side chain.

[0018] Furthermore, the response strategies executed by the smart contract include at least two of the following: access blocking, access permission adjustment, alarm notification, and audit marking.

[0019] Furthermore, it also includes: using zero-knowledge proofs to verify the compliance of access behavior, and completing the proof of the legality of permissions without exposing the original medical data.

[0020] In one embodiment of the present invention, a blockchain-based medical data access behavior auditing and unauthorized access detection system is provided, comprising: a behavior collection module, a risk assessment module, a hierarchical control module, an audit construction module, a blockchain evidence storage module, a smart contract module, and a model update module.

[0021] Furthermore, the blockchain evidence storage module adopts a permissioned chain structure and achieves node consistency through PBFT or Raft consensus mechanisms.

[0022] In one embodiment of the present invention, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the above-described method.

[0023] Based on the above technical solutions, the present invention provides a blockchain-based method and system for auditing and detecting unauthorized access to medical data. By performing structured modeling of medical data access behavior and combining access control policy models and behavior learning models for multi-source fusion risk assessment, the system performs graded processing and audit log construction according to risk levels. It utilizes a blockchain evidence storage mechanism that coordinates the main chain and side chains to achieve tamper-proof storage of audit data and achieves automated verification and response through smart contracts. At the same time, the audit results are fed back to dynamically optimize the model, thereby solving the problems of easy tampering of audit data, lagging detection of unauthorized behavior, and difficulty in balancing auditing and privacy protection in the prior art.

[0024] Furthermore, by constructing the multi-dimensional access behavior feature vector, the access behavior is transformed from a single permission determination into a comprehensive analysis process driven by multi-dimensional features, which improves the ability to characterize complex access scenarios and thus enhances the accuracy of unauthorized behavior identification.

[0025] Furthermore, by integrating the access control policy model with the behavior learning model and generating a comprehensive risk value based on dynamic weighting, the synergistic effect of rule judgment and behavior prediction is achieved, thereby improving the detection capability of covert unauthorized behavior while ensuring the determinism of access control.

[0026] Furthermore, by using a risk-driven tiered processing mechanism, access behavior is coupled with audit processing strategies, enabling high-risk behaviors to be blocked in real time and recorded on the blockchain immediately, while low-risk behaviors are processed in batches. This reduces the storage pressure on the blockchain and improves the overall processing efficiency of the system while ensuring security.

[0027] Furthermore, the audit logs are aggregated using a Merkle tree structure, and the Merkle root is written into the main chain, which effectively compresses the amount of on-chain data. At the same time, the Merkle proof mechanism is used to ensure the integrity and verifiability of off-chain data, thereby improving storage efficiency while ensuring the credibility of audit data.

[0028] Furthermore, through a blockchain architecture that coordinates the main chain and side chains, summary information and complete data are stored separately, and consistency verification is achieved through a cross-chain verification mechanism, thereby balancing system performance, data security, and cross-institutional auditing capabilities.

[0029] Furthermore, by using smart contracts to automate the execution of audit verification and response strategies, unauthorized behavior can trigger control measures immediately after detection, reducing manual intervention and improving the real-time nature and automation of audit responses.

[0030] Furthermore, by feeding the audit verification results back to the behavior learning model, the model can be dynamically updated and adaptively optimized, enabling the system to continuously improve its detection capabilities as access behavior changes, thereby enhancing the system's long-term stability and accuracy.

[0031] Furthermore, by introducing a zero-knowledge proof mechanism, access compliance verification can be completed without exposing the original medical data content, thereby achieving trusted auditing while ensuring privacy and security.

[0032] In summary, this invention achieves a closed-loop processing of medical data access behavior from real-time detection to trusted auditing and continuous optimization through a collaborative mechanism of "multi-model fusion detection—risk-level processing—blockchain-layered evidence storage—smart contract automatic response—model feedback optimization," thereby improving the system's overall performance in terms of security, real-time performance, reliability, and scalability. Attached Figure Description

[0033] Figure 1 This paper illustrates the overall process of a blockchain-based medical data access behavior audit and unauthorized access detection method in an embodiment of the present invention. The process includes steps such as structured modeling of access behavior, multi-source fusion risk assessment, risk-driven hierarchical processing, construction of audit logs and generation of data fingerprints, blockchain notarization, and verification and response based on smart contracts.

[0034] Figure 2 The diagram illustrates the module structure of a blockchain-based medical data access behavior audit and unauthorized access detection system in an embodiment of the present invention. The system includes a behavior collection module, a risk assessment module, a hierarchical control module, an audit construction module, a blockchain evidence storage module, a smart contract module, and a model update module. The modules work collaboratively through data interaction.

[0035] Figure 3The diagram illustrates the collaborative evidence storage structure of the main chain and side chains and the Merkle tree construction process in an embodiment of the present invention. In this embodiment, multiple audit logs are used to construct a Merkle tree structure through hash calculation to generate a Merkle root. The Merkle root is written to the main chain, which is used to store summary information. The side chain or off-chain storage is used to store complete audit log data. Data consistency verification is achieved through Merkle proof.

[0036] Explanation of reference numerals in the attached figures: 100—Behavior Acquisition Module; 110—Access Behavior Capture Unit; 120—Data Parsing and Feature Extraction Unit; 130—Access Behavior Standardization Unit; 200—Risk Assessment Module; 210—Strategy Analysis Unit; 220—Behavior Analysis Unit; 230—Integrated Decision Unit; 300—Hierarchical Control Module; 310—Hierarchical Judgment Unit; 320—Control Strategy Execution Unit; 330—Audit Strategy Linkage Unit; 400—Audit Construction Module; 410—Audit Log Generation Unit; 420—Log Structure Organization Unit; 430— Hash processing unit; 440—Merkel tree construction unit; 500—Blockchain evidence storage module; 510—Main chain storage unit; 520—Side chain storage unit; 530—Consensus processing unit; 540—Data verification unit; 600—Smart contract module; 610—Data verification unit; 620—Rule execution unit; 630—Response control unit; 700—Model update module; 710—Data acquisition unit; 720—Feature reconstruction unit; 730—Model training unit; 740—Parameter update unit; 800—Compliance proof unit. Detailed Implementation

[0037] To make the technical solution, technical features and beneficial effects of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0038] It should be noted that, in this specification, unless otherwise expressly specified and limited, the terms "comprising" and "including" should be interpreted broadly, meaning that the stated features, steps, or components are present, but not excluding the presence of other features, steps, or components.

[0039] In this embodiment, such as Figures 1 to 3 As shown, the present invention provides a blockchain-based method and system for auditing and detecting unauthorized access to medical data. It integrates the technical aspects of access behavior collection, risk assessment, hierarchical control, audit construction, blockchain notarization, and smart contract response into a cohesive design, based on the processing flow of medical data access behavior. This design enables a collaborative processing mechanism in which the technical aspects are interconnected and mutually restrictive.

[0040] Specifically, this invention uses the risk assessment results of access behavior as the core control basis for subsequent processing, establishing a correlation between access control policies, audit log construction methods, and blockchain storage methods, thereby achieving integrated processing of access behavior detection, audit records, and trusted evidence storage.

[0041] Based on the above overall design, the present invention forms a system architecture consisting of a behavior acquisition module 100, a risk assessment module 200, a hierarchical control module 300, an audit construction module 400, a blockchain evidence storage module 500, a smart contract module 600, and a model update module 700. The modules interact with each other through data to achieve linkage processing. The specific structure and working process will be described in detail below with reference to the accompanying drawings.

[0042] Furthermore, it should be understood that the following embodiments are merely preferred embodiments of the present invention, used to illustrate the technical solutions of the present invention, and not to limit the scope of protection of the present invention.

[0043] I. Overall Implementation Framework (combined with) Figure 1 and Figure 2 ) In one implementation, such as Figure 1 and Figure 2 As shown, the present invention provides a blockchain-based medical data access behavior auditing and unauthorized access detection system, which is applied to the data access control and auditing scenarios of medical information systems to perform real-time detection, hierarchical control and trusted evidence storage of medical data access behavior.

[0044] The system includes: Behavior collection module 100 Risk assessment module 200 Hierarchical control module 300 Audit Module 400 Blockchain Evidence Storage Module 500 Smart Contract Module 600 Model update module 700 The above modules form an integrated processing flow through data interaction, and its overall operation process is as follows: Figure 1 As shown.

[0045] In this embodiment, the behavior acquisition module 100 is connected to the data access interface of the medical information system, and is used to capture the access behavior in real time and generate access behavior data when the user initiates an access request for medical data; the access behavior data is transmitted to the risk assessment module 200 for analysis and processing.

[0046] The risk assessment module 200 is used to conduct a comprehensive risk assessment of access behavior based on access control policies and historical behavior data, and output the corresponding risk assessment results; the risk assessment results are sent to the hierarchical control module 300.

[0047] The hierarchical control module 300 performs hierarchical processing of access behavior based on the risk assessment results, generates corresponding access control decisions, and sends the access behavior and its processing results to the audit construction module 400.

[0048] The audit construction module 400 is used to generate audit log data based on access behavior data and access control decisions, and to perform hash processing and structured organization on the audit log data to form a data structure suitable for blockchain storage; the data structure is sent to the blockchain evidence storage module 500.

[0049] The blockchain evidence storage module 500 constructs a blockchain storage system based on the main chain and side chains for distributed storage of audit log data. The audit log summary information is written to the main chain, while the side chain or off-chain storage is used to store the complete audit log data, and the data consistency is ensured through a data verification mechanism.

[0050] The smart contract module 600 is deployed in the blockchain network to verify the audit log data and automatically trigger a preset response strategy when abnormal access behavior is detected, so as to realize the linkage execution of access control and audit verification.

[0051] The model update module 700 is used to receive audit result data from the blockchain evidence storage module 500 and the smart contract module 600, and update the risk assessment model based on the audit results to improve the accuracy of subsequent access behavior risk assessment.

[0052] In the above implementation, the collaborative relationships between the modules are as follows: After acquiring access behavior data, the behavior acquisition module 100 transmits it to the risk assessment module 200 for analysis. The risk assessment module 200 outputs the risk assessment results and transmits them to the hierarchical control module 300. The hierarchical control module 300 generates access control decisions based on the risk assessment results and sends the access behavior and its decision results to the audit construction module 400. The audit construction module 400 generates audit logs and transmits them to the blockchain evidence storage module 500 for storage. The blockchain evidence storage module 500 verifies the data and executes response operations through the smart contract module 600, while simultaneously feeding back the audit results to the model update module 700 to complete model optimization.

[0053] Furthermore, in this embodiment, by linking the risk assessment results with access control decisions, audit log construction, and blockchain evidence storage processes, the detection, processing, and evidence storage of access behaviors are integrated into a unified processing mechanism, thereby achieving collaborative operation between access control and audit evidence storage.

[0054] Specifically, the risk assessment results of access behavior are used not only to determine access control policies, but also to determine the generation method of audit logs and the blockchain storage method, thereby improving the blockchain storage efficiency while ensuring system security.

[0055] Through the above-described overall implementation framework, this invention realizes a closed-loop processing flow for medical data access behavior, from real-time detection, hierarchical processing, audit recording to trusted evidence storage and model optimization, thereby improving the system's processing efficiency and audit reliability while ensuring data security.

[0056] II. Behavior Collection Module In one implementation, such as Figure 2 As shown, the behavior acquisition module 100 is located at the data access interface of the medical information system and is used to capture, parse and structure the access behavior during the medical data access process in real time.

[0057] Specifically, the behavior acquisition module 100 can be deployed in the data access interface layer of systems such as Hospital Information System (HIS), Electronic Medical Record System (EMR), and Medical Imaging System (PACS) in the form of an interface proxy component, gateway plugin, or middleware, thereby achieving non-intrusive acquisition of access behavior without changing the original system structure.

[0058] 2.1 Access Behavior Capture Unit The behavior acquisition module 100 includes an access behavior capture unit 110, which is used to monitor and capture access requests in real time when a user initiates a data access request.

[0059] In one implementation, the access behavior capture unit 110 acquires access behavior data in the following manner: Listen for application API call requests; Capture database access commands; Analyze API access logs; The raw access data acquired by the access behavior capture unit 110 includes, but is not limited to: Access subject identifier (such as user ID, role information); Accessed data identifiers (such as patient ID, data resource identifier); Operation type (e.g., query, modify, delete); Access time information; Request source information (such as IP address, device identifier).

[0060] 2.2 Data parsing and feature extraction unit (120) The behavior acquisition module 100 also includes a data parsing and feature extraction unit 120, which is used to parse the raw access data acquired by the access behavior capture unit 110 and extract key feature information for subsequent risk assessment.

[0061] In one implementation, the data parsing and feature extraction unit 120 processes the access behavior as follows: Perform identity attribute parsing on the access subject information; Add sensitivity level labels to the accessed data; Classify access behaviors by operation type; Extract time features from time information; Conduct a security level assessment of environmental information; Furthermore, the data parsing and feature extraction unit 120 encapsulates the above information in a unified format to generate structured access behavior data.

[0062] 2.3 Standardized Access Behavior Unit The behavior acquisition module 100 also includes an access behavior standardization unit 130, which is used to uniformly standardize the structured access behavior data to form standardized access behavior events.

[0063] In one implementation, the access behavior standardization unit 130 processes the access behavior data as follows: Unify field format and encoding rules; Complete or mark missing fields; Filter or correct abnormal data; After standardization, access behavior event data in a unified format is generated.

[0064] 2.4 Data Output and Interface Integration In this embodiment, the behavior acquisition module 100 outputs standardized access behavior event data to the risk assessment module 200 as input data for subsequent risk assessment processing.

[0065] Furthermore, to ensure the consistency of data transmission between modules, the access behavior event data is represented using a unified data structure and transmitted through a standard interface.

[0066] 2.5 Module Synergy and Technical Effects In the above implementation, by integrating access behavior capture, feature extraction and standardization processing into the behavior acquisition module 100, a unified modeling of medical data access behavior is achieved, thereby providing standardized and structured data input for the subsequent risk assessment module 200.

[0067] Furthermore, since the behavior acquisition module 100 completes data structuring processing when the access behavior occurs, subsequent risk assessment and auditing can be carried out based on a unified data structure, thereby improving the overall processing efficiency of the system and reducing data conversion overhead.

[0068] Furthermore, by uniformly extracting and encapsulating the multidimensional features in access behavior data, access behavior can be used not only for permission determination but also for anomaly detection and blockchain evidence storage, thus providing a data foundation for the collaborative processing of access behavior detection, auditing, and evidence storage.

[0069] III. Risk Assessment Module In one implementation, such as Figure 1 As shown, the risk assessment module 200 is connected to the behavior collection module 100 and is used to comprehensively analyze and process the standardized access behavior event data output by the behavior collection module 100, and output a risk assessment result to characterize the degree of access risk.

[0070] The risk assessment module 200 includes: Strategy Analysis Unit 210 Behavioral Analysis Unit 220 Integrated Decision Unit 230 The aforementioned units form a collaborative processing mechanism through data interaction.

[0071] 3.1 Strategy Analysis Unit The strategy analysis unit 210 is used to perform rule matching analysis on access behavior based on a preset access control policy.

[0072] In one implementation, the access control policy includes, but is not limited to: Role-based access control policy; Attribute-based access control policies; Access control policies based on time or environmental constraints; The strategy analysis unit 210 matches and judges the access behavior based on the access subject information, data identifier and access environment information in the access behavior event data, and outputs the strategy judgment result.

[0073] Furthermore, the policy determination result is used to characterize whether the access behavior meets the preset access rules, and serves as one of the inputs for subsequent fusion decisions.

[0074] 3.2 Behavioral Analysis Unit The behavior analysis unit 220 is used to analyze the degree of abnormality of the current access behavior based on historical access behavior data.

[0075] In one implementation, the behavior analysis unit 220 establishes a normal pattern of access behavior by performing statistical analysis or model training on historical access behavior data, and compares and analyzes the current access behavior with the normal pattern to obtain an assessment result of the degree of abnormality of the access behavior.

[0076] Furthermore, the behavior analysis unit 220 can perform analysis based on the following information: User's historical access frequency; Data access distribution characteristics; Access time mode; Access path associations; The above analysis enables the identification of potential abnormal access behaviors even when the access behavior conforms to the basic permission rules.

[0077] 3.3 Integrated Decision-Making Unit The fusion decision unit 230 is used to comprehensively process the strategy determination result of the strategy analysis unit 210 and the anomaly evaluation result of the behavior analysis unit 220 to generate a unified risk assessment result.

[0078] In one implementation, the fusion decision unit 230 performs a joint determination on the two types of analysis results according to a preset fusion rule, thereby obtaining a risk assessment result used to characterize the degree of risk of access behavior.

[0079] Furthermore, the fusion decision unit 230 can dynamically adjust the fusion rules based on the access scenario or historical evaluation results to improve the accuracy of risk assessment.

[0080] 3.4 Risk Assessment Results Output In this embodiment, the risk assessment module 200 outputs the generated risk assessment results to the hierarchical control module 300 for subsequent access control decisions and audit processing.

[0081] The risk assessment results are used to characterize the risk level of the access behavior and serve as a key control basis for subsequent processing procedures.

[0082] 3.5 Technical Effects Description In the above implementation, the policy determination result output by the policy analysis unit 210 and the anomaly assessment result output by the behavior analysis unit 220 are comprehensively processed by the fusion decision unit 230 to generate a unified risk assessment result. The risk assessment result is output to the hierarchical control module 300 and the audit construction module 400 as the basis for subsequent access control, audit processing, and evidence storage. Through this processing method, the system can combine rule-based access control analysis with behavior-based anomaly analysis, ensuring the reliability of access control while improving the ability to identify abnormal access behavior and providing a unified input for subsequent processing flows.

[0083] IV. Hierarchical Control Module In one implementation, such as Figure 1 As shown, the hierarchical control module 300 is connected to the risk assessment module 200 and is used to perform hierarchical processing on access behavior based on the risk assessment results output by the risk assessment module 200, and generate corresponding access control decisions and audit processing strategies.

[0084] 4.1 Grading Determination Unit The hierarchical control module 300 includes a hierarchical determination unit 310, which is used to determine the risk level of the access behavior based on the risk assessment results.

[0085] In one implementation, the classification and determination unit 310 classifies access behavior into at least three categories based on a preset risk range: High-risk access behavior; Medium-risk access behavior; Low-risk access behavior; Furthermore, the risk level classification rules can be dynamically adjusted according to the system's operating conditions.

[0086] 4.2 Control Strategy Execution Unit The hierarchical control module 300 further includes a control policy execution unit 320, which is used to execute the corresponding access control policy according to the risk level.

[0087] In one implementation: When an access behavior is determined to be high-risk, the control policy execution unit 320 performs an access blocking operation and generates an abnormal access identifier. When the access behavior is determined to be of medium risk, the control policy execution unit 320 triggers an approval process or an alarm notification. When the access behavior is determined to be low risk, the control policy execution unit 320 allows the access to continue; 4.3 Audit Strategy Coordination Unit The hierarchical control module 300 also includes an audit strategy linkage unit 330, which is used to determine the corresponding audit log generation method and blockchain evidence storage strategy based on the risk level of the access behavior.

[0088] In one implementation: For high-risk access behaviors, the audit strategy linkage unit 330 controls the audit construction module 400 to generate audit logs in real time and marks them as priority data to be uploaded to the chain. For medium-risk access behavior, the audit strategy linkage unit 330 controls the generation of audit logs with risk indicators and triggers the key audit mechanism; For low-risk access behavior, the audit strategy linkage unit 330 controls the audit logs to enter the batch processing queue for aggregation and unified storage; 4.4 Data Output and Process Integration In this embodiment, the hierarchical control module 300 outputs access control decisions and corresponding audit processing strategies to the audit construction module 400.

[0089] Furthermore, the hierarchical control module 300 not only controls access behavior, but also controls the generation method of audit data and the subsequent evidence storage method, thereby realizing the linkage between the access control process and the audit evidence storage process.

[0090] 4.5 Module Collaboration Relationship and Technical Effects In the above implementation, the hierarchical control module 300 associates risk assessment results with access control policies and audit processing policies, ensuring that the processing of access behavior includes not only whether access is allowed but also the corresponding audit processing method. For access behaviors with different risk levels, the system performs actions such as blocking, approval, alarm, or allowing access, and generates audit logs of different types. High-risk access behaviors correspond to immediate audit processing, while low-risk access behaviors correspond to batch audit processing. Through this hierarchical control method, the system can differentiate the control of subsequent processing flows according to the risk level of access behavior, providing a basis for audit log construction and blockchain evidence storage.

[0091] In one implementation, the risk level output by the hierarchical control module 300 is used not only to determine the processing method for access behavior but also to determine the construction and subsequent storage method of audit logs. Specifically, when an access behavior is determined to be high-risk, the system executes access blocking and generates an independent audit log, which is given priority in the blockchain verification and evidence storage process; when an access behavior is determined to be medium-risk, the system generates an audit log with a risk label and triggers an approval or key audit process; when an access behavior is determined to be low-risk, the system allows access and adds the corresponding audit log to a batch processing queue. After reaching a preset time window or log quantity threshold, a Merkle tree is constructed and a Merkle root is generated. Through the above method, the risk assessment results are simultaneously involved in access control, log organization, and storage processing, thereby achieving linkage between various processing links.

[0092] Audit building blocks In one implementation, such as Figure 1 and Figure 3 As shown, the audit construction module 400 is connected to the hierarchical control module 300, and is used to generate audit log data based on access behavior data and hierarchical control results, and to perform structured processing and hash calculation on the audit log data to form a data structure suitable for blockchain storage.

[0093] 5.1 Audit Log Generation Unit The audit construction module 400 includes an audit log generation unit 410, which generates audit log data based on access behavior data and corresponding access control decisions.

[0094] In one implementation, the audit log data includes at least: Access behavior data; Risk assessment results; Access control decisions; Timestamp information; Furthermore, the audit log generation unit 410 marks the audit logs according to the risk level information output by the hierarchical control module 300 in order to distinguish access behaviors of different risk levels.

[0095] 5.2 Log Structure Organization Units (420) (Key Feature) The audit construction module 400 also includes a log structure organization unit 420, which is used to perform differentiated organization and processing of audit log data according to the risk level of access behavior.

[0096] In one implementation: For high-risk access behaviors, the log structure organization unit 420 organizes the corresponding audit logs in the form of independent data units to support real-time processing and priority evidence storage. For low-risk access behavior, the log structure organization unit 420 aggregates multiple audit log data according to a preset time window to form a log data set; Furthermore, the log data set is used to subsequently construct the Merkle tree structure.

[0097] 5.3 Hash Processing Unit The audit construction module 400 further includes a hash processing unit 430, which performs hash calculations on the audit log data or log data set to generate corresponding data fingerprints.

[0098] In one implementation: Perform hash calculation on a single audit log entry to generate a corresponding log hash value; Perform hash calculations on each log entry in the aggregated log set; The hash result output by the hash processing unit 430 is used to subsequently construct the Merkle tree structure.

[0099] 5.4 Merkle Tree Building Unit The audit building module 400 also includes a Merkle tree building unit 440, which is used to build a Merkle tree structure based on the hash processing result.

[0100] In one implementation: Use multiple log hash values ​​as leaf nodes; Generate a parent node by performing a combined hash calculation on adjacent nodes; Calculate layer by layer until a unique Merkle root is generated; The Merkle root is used to characterize the overall data fingerprint of this batch of audit log data.

[0101] 5.5 Data Output and Blockchain Integration In this embodiment: For audit logs corresponding to high-risk access behaviors, the audit construction module 400 directly outputs a single log data and its hash result to the blockchain evidence storage module 500. For the log set corresponding to low-risk access behavior, the audit construction module 400 outputs Merkle root and related index information to the blockchain evidence storage module 500. 5.6 Module Collaboration Relationship and Technical Effects In the above implementation, the risk level information output by the hierarchical control module 300 is incorporated into the audit log construction process, ensuring that the organization of the audit logs corresponds to the risk of the access behavior. For access behaviors requiring immediate processing, the system generates independent audit logs; for access behaviors suitable for batch processing, the system aggregates multiple audit logs and constructs a Merkle tree structure. Furthermore, by organizing the hash results of multiple audit logs into a Merkle tree and generating a Merkle root, a batch of audit log data can be represented in summary form, thereby reducing the amount of data stored on the blockchain. Simultaneously, any audit log can be verified in conjunction with its corresponding path information to ensure data integrity and verifiability. Through this processing method, the audit log construction process can be effectively integrated with the subsequent blockchain evidence storage process.

[0102] VI. Blockchain Evidence Storage Module In one implementation, such as Figure 3 As shown, the blockchain evidence storage module 500 is connected to the audit construction module 400 and is used for distributed storage and trusted evidence storage of audit log data to ensure the immutability and verifiability of audit data.

[0103] The blockchain evidence storage module 500 includes: Main chain storage unit 510 Sidechain storage unit 520 Consensus Processing Unit 530 Data verification unit 540 6.1 Main chain storage unit (510) The main chain storage unit 510 is used to store summary information of the audit logs.

[0104] In one implementation, the main chain storage unit 510 receives data digest information output from the audit construction module 400, including: Merkelgen; Timestamp information; Log index information; The main chain storage unit 510 packages the above-mentioned summary information into block data and broadcasts it through the blockchain network.

[0105] Furthermore, the main chain uses a chain structure to store block data, with each block containing the hash value of the previous block, thus forming an immutable data chain.

[0106] 6.2 Sidechain storage unit (520) The sidechain storage unit 520 is used to store complete audit log data.

[0107] In one implementation: For log sets formed by low-risk access behaviors, the sidechain storage unit 520 stores complete log data; For high-risk access behaviors, the sidechain storage unit 520 stores the corresponding log details and establishes an association with the main chain summary information; Furthermore, the sidechain storage unit 520 can be implemented using an independent blockchain or a distributed storage system.

[0108] 6.3 Consensus Processing Unit The blockchain evidence storage module 500 also includes a consensus processing unit 530, which is used to verify the data to be uploaded to the blockchain and reach a consensus.

[0109] In one implementation, the consensus processing unit 530 operates based on a permissioned blockchain mechanism, and the participating nodes include: Medical institution nodes; Data monitoring nodes; Audit nodes; The consensus processing unit 530 uses the Byzantine fault-tolerant algorithm or the Raft algorithm to verify and confirm the block data, thereby ensuring the reliability of data writing.

[0110] 6.4 Data Verification Unit (540) The blockchain evidence storage module 500 also includes a data verification unit 540, which is used to verify the consistency between the sidechain data and the main chain digest.

[0111] In one embodiment, the data verification unit 540 performs the following operations: Calculate its hash value based on the audit log to be verified; Calculate the corresponding Merkel root based on the Merkel path; The calculation results are compared with the Merkle root stored in the main chain; If the comparison results are consistent, it is determined that the audit log data has not been tampered with.

[0112] 6.5 Data Flow and Module Collaboration In this embodiment, the data digest and log data output by the audit construction module 400 are transmitted to the main chain storage unit 510 and the side chain storage unit 520, respectively. The main chain storage unit 510 completes block generation and on-chain processing through the consensus processing unit 530, and the data verification unit 540 performs consistency verification between the side chain data and the main chain digest. Through the above processing method, the main chain is used to store the summary information of the audit log, and the side chain or off-chain storage is used to store the complete audit log data, thereby achieving separate storage of summary data and detailed data. Furthermore, by recording Merkle root and index information on the main chain and combining it with the complete audit log data in the side chain or off-chain storage, consistency verification can be performed on any audit log, ensuring the verifiability of audit data while reducing the data storage pressure on the main chain. The consensus processing unit 530's consistency confirmation of the data to be on-chain also improves the reliability of the audit data writing process.

[0113] VII. Smart Contract Module In one implementation, such as Figure 1 and Figure 3 As shown, the smart contract module 600 is deployed in the blockchain network corresponding to the blockchain evidence storage module 500, and is used to verify the audit log data and automatically execute the preset access control response policy based on the verification result.

[0114] The smart contract module 600 includes: Data verification unit 610 Rule Execution Unit 620 Response Control Unit 630 The aforementioned units work together through on-chain execution logic.

[0115] 7.1 Data Validation Unit The data verification unit 610 is used to verify the consistency of the audit log data and its summary information uploaded to the blockchain.

[0116] In one implementation, the data verification unit 610 verifies the audit log data to be verified based on the Merkle root and corresponding index information stored in the blockchain, including: Obtain the hash value corresponding to the log to be verified; Calculate the corresponding summary results based on the Merkel path; The calculation results are compared with the digest information stored on the chain; When the verification results are consistent, the audit log data is determined to be reliable data.

[0117] The smart contract module 600 also includes a rule execution unit 620, which is used to execute preset audit rules based on audit log data and risk assessment results.

[0118] In one implementation, the rule execution unit 620 parses the audit log data and makes a judgment based on the following information: Risk level labeling; Access control decision results; Abnormal behavior markers; Furthermore, when an abnormal access behavior that meets preset conditions is detected, the rule execution unit 620 triggers the corresponding processing rule.

[0119] 7.3 Response Control Unit (630) The smart contract module 600 also includes a response control unit 630, which is used to automatically execute an access control response operation when the triggering condition of the rule execution unit 620 is met.

[0120] In one embodiment, the response operation performed by the response control unit 630 includes: Send an access blocking command to the medical information system; To restrict or adjust the permissions of the accessing entity; Generate alarm information and send it to the management terminal; Mark abnormal access behavior on the chain; Furthermore, the response control unit 630 interacts with the medical information system interface or control module to achieve real-time control of access behavior.

[0121] 7.4 Module Collaboration Relationships and Data Flow In this embodiment: The blockchain evidence storage module 500 writes audit log data and summary information into the blockchain; The data verification unit 610 performs consistency verification on the data; The rule execution unit 620 performs rule judgments based on the verified data; The response control unit 630 automatically triggers control operations based on the rule execution results; Furthermore, the smart contract module 600, risk assessment module 200, and hierarchical control module 300 form the following collaborative relationship: Risk assessment → Tiered control → Audit logs → Blockchain evidence storage → Smart contract verification → Automatic response Through the configuration of the aforementioned smart contract module 600, the system can perform verification processing based on on-chain audit data and trigger preset response operations according to the verification results. Thus, a linkage is established between the audit verification process and the access control process.

[0122] Furthermore, when abnormal access behavior is detected, the response control unit 630 can perform operations such as access blocking, permission adjustment, alarm notification, or abnormal marking, thereby improving the timeliness of handling abnormal access behavior.

[0123] Meanwhile, the execution results of smart contracts can be recorded and traced, facilitating subsequent auditing and management.

[0124] In one implementation, the system may further include a compliance verification unit (800) for verifying the legality of access behavior based on zero-knowledge proof.

[0125] Specifically, the compliance verification unit (800) is used to generate access permission legality verification based on the access subject's permission information and access policy without exposing the original medical data content; the access permission legality verification is proof data that meets preset verification rules.

[0126] Furthermore, the smart contract module (600) is used to receive the access permission validity certificate, and to verify the certificate based on preset verification logic. When the verification is successful, the access behavior is determined to meet the permission requirements.

[0127] In one implementation, the access permission validity proof can be generated based on a zero-knowledge proof protocol, enabling the verifier to confirm the validity of the access behavior without obtaining the original data content.

[0128] By employing the above methods, while ensuring the compliance verification of access behavior, the direct exposure of sensitive medical data during the verification process is avoided, thereby improving the system's security in terms of privacy protection.

[0129] VIII. Model Update Module (700) In one implementation, such as Figure 1 and Figure 2 As shown, the model update module 700 is connected to the smart contract module 600 and the blockchain evidence storage module 500, and is used to update the behavior learning model based on audit result data to improve the accuracy and adaptability of risk assessment.

[0130] The model update module 700 includes: Data acquisition unit 710 Feature Reconstruction Unit 720 Model training unit 730 Parameter update unit 740 The above-mentioned units form a model update process through data interaction.

[0131] 8.1 Data Acquisition Unit (710) The data acquisition unit 710 is used to obtain audit result data from the blockchain evidence storage module 500 and the smart contract module 600.

[0132] In one implementation, the audit result data includes: Audit log data; Risk assessment results; Access control decision results; Abnormal behavior marker information; Furthermore, since the audit data has been stored on the blockchain and verified by smart contracts, the data acquired by the data acquisition unit 710 is credible.

[0133] 8.2 Feature Reconstruction Unit (720) The model update module 700 further includes a feature reconstruction unit 720, which is used to perform feature extraction and reconstruction processing on the audit result data to generate the input data required for model training.

[0134] In one implementation, the feature reconstruction unit 720 processes the audit data as follows: Extract access behavior characteristics; Mark the risk level and anomaly category; Constructing behavioral sequence data; Furthermore, the training data generated by the feature reconstruction unit 720 is consistent with the input features in the risk assessment module 200, thereby ensuring data consistency between the model update process and the risk assessment process.

[0135] 8.3 Model Training Units (730) The model update module 700 also includes a model training unit 730, used to train or optimize the behavior learning model based on the training data.

[0136] In one implementation, the model training unit 730 processes the behavior learning model as follows: Update behavior pattern parameters; Adjust the anomaly detection threshold; Optimize behavioral relationships; Furthermore, the model training unit 730 can adopt an incremental training method to avoid causing a significant impact on the system operation.

[0137] 8.4 Parameter Update Unit (740) The model update module 700 also includes a parameter update unit 740, which is used to apply the trained model parameters to the behavior learning model in the risk assessment module 200.

[0138] In one implementation: The parameter update unit 740 transmits the updated model parameters to the risk assessment module 200; The risk assessment module 200 performs subsequent risk assessments based on the updated model; This allows the model update results to take effect immediately on the system operation.

[0139] 8.5 Module Collaboration Relationships and Data Flow In this embodiment, the model update module 700 forms the following data flow relationship with other modules: Audit Results → Data Collection → Feature Reconstruction → Model Training → Parameter Update → Risk Assessment Module Furthermore, the model update module 700 and the risk assessment module 200 form a feedback relationship, enabling the risk assessment model to be continuously optimized based on historical audit data.

[0140] In one implementation, the model update module 700 only collects data that has undergone audit processing and passed verification, and constructs model training samples based on this data. For abnormal access behaviors confirmed by audit, the system assigns an abnormal label; for access behaviors subsequently confirmed as false alarms, the system corrects the labels and updates the behavior learning model parameters in the next round of model training. Through this method, the model update process is based on reliable audit data, thereby improving the reliability of the risk assessment model update.

[0141] Through the configuration of the model update module 700, the system can update the behavior learning model based on audit result data and apply the updated model parameters to the risk assessment module 200 to support subsequent risk assessment processing of access behaviors. Since the data used for model updates comes from data that has already undergone audit processing, it provides a stable data foundation for model optimization. Through this update mechanism, the system can continuously adjust the risk assessment process based on the audit results generated during actual operation.

[0142] IX. System Collaboration Instructions In this embodiment, the behavior acquisition module 100, risk assessment module 200, hierarchical control module 300, audit construction module 400, blockchain evidence storage module 500, smart contract module 600, and model update module 700 are sequentially connected and work collaboratively. Specifically, the behavior acquisition module 100 is used to acquire and structure medical data access behavior; the risk assessment module 200 is used to analyze the access behavior and output risk assessment results; the hierarchical control module 300 determines the access processing method and audit processing method based on the risk assessment results; the audit construction module 400 generates audit logs and constructs corresponding data structures based on the access behavior and processing results; the blockchain evidence storage module 500 stores and verifies the consistency of audit data; the smart contract module 600 performs verification and response based on the audit data; and the model update module 700 updates the risk assessment model based on the audit results. Through the above processing flow, the system can complete the acquisition, analysis, processing, recording, evidence storage, response, and updating of medical data access behavior, forming a continuous data flow process.

[0143] In summary, this invention, through a holistic design of the medical data access behavior processing flow, integrates risk assessment, hierarchical control, audit construction, blockchain notarization, smart contract response, and model updates to achieve the detection, auditing, notarization, and subsequent processing of medical data access behavior. By employing a risk-level-based hierarchical processing mechanism and a storage method that stores summary information on the main chain and complete audit logs on side chains or off-chain, the system improves processing efficiency while ensuring the verifiability of audit data.

[0144] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit the scope of protection of the present invention. For those skilled in the art, various modifications, equivalent substitutions or improvements can be made to the above embodiments without departing from the spirit and substance of the present invention, and all such modifications, substitutions or improvements should fall within the scope of protection of the present invention.

[0145] Furthermore, the technical features of the various embodiments described in this specification can be combined or substituted with each other without conflict. All equivalent changes or modifications made based on the technical concept of this invention should be covered within the scope of protection of this invention.

Claims

1. A blockchain-based method for auditing and detecting unauthorized access to medical data, characterized in that, Includes the following steps: S1: Structured modeling of access behavior: Collect data access requests from medical information systems and extract access subject identifiers, data identifiers, operation types, time information, and contextual information to construct a multi-dimensional access behavior feature vector; S2: Risk Assessment of Multi-Source Fusion The access behavior feature vector is input into the access control policy model and the behavior learning model to obtain the policy judgment result and the behavior anomaly score, respectively, and a comprehensive risk value is generated based on the preset fusion function. S3: Risk-driven tiered processing mechanism: Risk levels are classified based on the comprehensive risk value, where: High-risk access triggers real-time blocking and immediate audit log generation; Access to medium-risk sites triggers approval or an alert. Low-risk access allows execution and entry into the batch audit process; S4: Hierarchical Log Construction and Fingerprint Generation Structured audit logs are generated for the access behavior and its risk results, and Merkle trees are constructed in real time or in batches according to the risk level to generate corresponding log data fingerprints; S5: Main chain-side chain collaborative notarization: The data fingerprint and digest information are written into the main chain, the complete audit log is stored in the side chain or off-chain storage, and the consistency verification between the main chain and the side chain is achieved through Merkel proof. S6: Smart contract-based linkage verification and response: The audit data is verified using blockchain smart contracts, and access control response policies are automatically executed according to the risk level. The verification results are then fed back to the behavior learning model for dynamic updates.

2. The method according to claim 1, characterized in that, The access behavior feature vector includes: User identity attributes, data sensitivity level, access frequency, time distribution characteristics, and environmental security parameters, at least three of the following:

3. The method according to claim 1, characterized in that, The behavior learning model includes: A time-series-based behavior prediction model and a relationship graph-based behavior association model are used to calculate time-series anomaly scores and structural anomaly scores, respectively.

4. The method according to claim 1, characterized in that, The fusion function is a dynamic weighting function, and its weights are adaptively adjusted according to the access scenario and historical false alarm rate.

5. The method according to claim 1, characterized in that, The Merkle tree construction process includes: Within a preset time window, hash calculations are performed on multiple audit logs and the parent node hashes are generated by combining them in pairs until a unique Merkle root is generated.

6. The method according to claim 1, characterized in that, The main chain is used to store Merkle root and index information, while the side chain or off-chain storage is used to store complete audit log data, and Merkle proof is used to verify the consistency of data between the main chain and the side chain.

7. The method according to claim 1, characterized in that, The response strategies executed by the smart contract include: At least two of the following: access blocking, access permission adjustment, alarm notification, and audit marking.

8. The method according to claim 1, characterized in that, Also includes: Zero-knowledge proofs are used to verify the compliance of access behavior, and the legality of permissions is proven without exposing the original medical data.

9. A blockchain-based medical data access behavior auditing and unauthorized access detection system, characterized in that, include: The behavior acquisition module is used to generate access behavior feature vectors; The risk assessment module is used to generate a comprehensive risk value based on the strategy model and the behavior learning model; The hierarchical control module is used to execute access control and log generation policies according to risk levels; The audit building module is used to generate audit logs and construct Merkle trees; The blockchain evidence storage module is used to write the data fingerprint and summary information of the audit log into the main chain, store the complete audit log in the side chain or off-chain storage, and realize the consistency verification of the main chain and side chain data through Merkel proof. The smart contract module is used to perform audit verification and automatic response; The model update module is used to dynamically optimize the behavior learning model based on audit results; The blockchain evidence storage module adopts a permissioned chain structure and achieves node consistency through PBFT or Raft consensus mechanisms.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 8.

Images