Electronic signature rollback control method
By constructing a dynamic permission matrix and using blockchain for evidence storage, the problems of imprecise permission management and insufficient risk assessment in electronic medical record signature rollback are solved, achieving accurate permission verification and comprehensive risk control, and ensuring the security and traceability of electronic medical record data.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- NANJING YUNMAI SHANGBO INFORMATION TECHNOLOGY CO LTD
- Filing Date
- 2025-08-05
- Publication Date
- 2026-06-23
AI Technical Summary
Existing electronic medical record signature rollback methods suffer from insufficiently granular access control, an inability to dynamically allocate operation permissions based on physician level and medical record type, a lack of effective risk pre-screening mechanisms, leading to data security issues and legal disputes, incomplete operation record storage, and difficulty in traceability.
A dynamic permission matrix is constructed, which includes physician level, medical record type and operation permission dimensions. Through risk pre-examination assessment and blockchain evidence storage, refined permission management and operation traceability are achieved. Multi-level rollback operations are adopted and the results are synchronized to blockchain storage.
It enables precise permission verification and comprehensive risk control for electronic signature rollback operations, ensuring data security and operational traceability, and improving data credibility and compliance.
Smart Images
Figure CN120878022B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of data security processing technology, specifically an electronic signature rollback control method. Background Technology
[0002] In electronic medical record systems, the rollback of electronic signatures is a crucial and complex step. Existing electronic medical record signature rollback methods suffer from several problems. For example, access control is not granular enough, failing to dynamically allocate operation permissions based on factors such as physician level and medical record type, making it prone to abuse. There is a lack of effective risk pre-detection mechanisms, failing to promptly control potential risks such as high-frequency rollbacks, rollbacks of overdue archived medical records, and operations on sensitive fields, potentially leading to data security issues and legal disputes. Furthermore, the evidence preservation of operation records is inadequate, making it difficult to guarantee the traceability and immutability of rollback operations, hindering the resolution of medical disputes and regulatory auditing. Therefore, a more secure, reliable, and granular electronic signature rollback control method is needed. Summary of the Invention
[0003] To address the shortcomings of existing technologies, this invention proposes an electronic signature rollback control method. This method constructs a dynamic permission matrix encompassing physician level, medical record type, and operation permission dimensions, and pre-stores a hierarchical permission table. It receives electronic signature rollback requests containing information such as the initiator's identifier, retrieves the electronic medical record file to be processed and the signature chain information based on the request, and performs risk pre-assessment and risk control. Based on the dynamic permission matrix, it verifies the operator's operation permissions and uploads the results to the blockchain for evidence storage. Upon successful permission verification, it executes multi-level rollback operations according to the target rollback state and signature chain sequence, tracing back to the target signature node and restoring the medical record content. After completion, it synchronizes the electronic medical record snapshots before and after the rollback, permission records, and operation logs to the blockchain storage. This invention ensures the security and traceability of electronic signature rollback operations through multi-dimensional dynamic permission control and blockchain evidence storage.
[0004] To achieve the above objectives, the present invention provides the following technical solution:
[0005] An electronic signature rollback control method includes:
[0006] S1: Construct a dynamic permission matrix and pre-store a hierarchical permission table, which includes physician level dimension, medical record type dimension and operation permission dimension;
[0007] S2: Receive an electronic signature rollback request, wherein the electronic signature rollback request includes the initiator identifier, the target rollback status, and the unique identifier of the electronic medical record to be rolled back;
[0008] S3: Based on the unique identifier of the electronic medical record to be rolled back in the rollback request, obtain the electronic medical record file to be processed and the corresponding signature chain information. The electronic medical record file includes medical record content and medical record type identifier. The signature chain information includes signature chain sequence, circulation status, and sensitive field markers.
[0009] S4: Based on the acquired electronic medical record files and signature chain information, perform risk pre-checks and conduct risk assessments and controls on electronic signature rollback requests;
[0010] S5: Verify the operation permissions of the operator who initiated the electronic signature rollback request based on the dynamic permission matrix, obtain the permission verification result, and upload the permission verification result to the blockchain for storage;
[0011] S6: If the permission verification result is passed, perform a multi-level rollback operation of the electronic signature according to the target rollback state and the signature chain sequence, backtrack to the signature node corresponding to the target rollback state and restore the electronic medical record content of the node, and after the multi-level rollback operation is completed, synchronize the electronic medical record snapshot before rollback, the electronic medical record snapshot after rollback, the permission records and operation logs involved in this rollback to the blockchain for storage.
[0012] Specifically, constructing the dynamic permission matrix includes:
[0013] S1.1: Collect historical rollback operation records, and use frequency statistics combined with a pre-built risk assessment model to statistically analyze the rollback operation frequency and risk coefficient of different physician levels for different types of medical records. The risk assessment model is constructed based on the analytic hierarchy process.
[0014] S1.2: Based on the statistical results, use the permission mapping algorithm to set the initial permission mapping relationship and form the basic permission table;
[0015] S1.3: Set dynamic permission adjustment rules, and monitor physician level changes and new medical record type events in real time through system monitoring, including:
[0016] When a physician's level changes, a permission update procedure is triggered. The permission update procedure automatically updates the corresponding physician's permission record in the basic permission table according to the pre-set level and permission correspondence rules. When a new medical record type is added, default permissions are automatically assigned to each physician level based on the permission inheritance principle of similar medical record types, and the new permission record is added to the basic permission table.
[0017] S1.4: Integrate the basic permission table with the dynamic adjustment rules to generate a dynamic permission matrix and store it in a distributed database. The distributed database supports real-time read and write operations and permission change synchronization.
[0018] Specifically, obtaining the electronic medical record file to be processed and the corresponding signature chain information includes:
[0019] S3.1: Use a string parsing algorithm to parse the unique identifier of the electronic medical record to be rolled back and determine the storage path of the electronic medical record;
[0020] S3.2: Retrieve the electronic medical record file from the corresponding path in the electronic medical record database. The medical record content includes the patient's basic information, diagnostic records, treatment plans, and examination reports.
[0021] S3.3: Use a unique identifier as the query keyword to query the signature chain information stored in the blockchain. The signature chain sequence records the signer identifier, signature time, and signature type of each signature node in timestamp order.
[0022] S3.4: Extract the current circulation status and sensitive field markers from the signature chain information. The sensitive field markers are implemented using text annotation technology, which is achieved by combining a natural language processing model with a rule engine.
[0023] Specifically, the steps of S4 include: based on the signature chain sequence, using a frequency statistics algorithm to count the initiator's rollback frequency within a preset time period, and combining this with a high-frequency rollback threshold to determine whether it is a high-frequency rollback; if it exceeds the high-frequency rollback threshold, it is considered a risk; obtaining the electronic medical record's circulation status from the signature chain information and matching it with a pre-set archiving status judgment rule; if it is in an overdue archiving status, it is considered a risk; identifying content marked with sensitive fields in the electronic medical record file; if the rollback operation involves modification of sensitive fields, it is considered a risk; outputting the risk pre-detection result; if any risk exists, the risk pre-detection result is "fail" and the process is terminated; otherwise, it is "pass" and S5 is executed.
[0024] Specifically, in step S5, the operation permissions of the operator initiating the electronic signature rollback request are verified based on the dynamic permission matrix to obtain the permission verification result, including:
[0025] The process involves matching the initiator's identifier with the corresponding physician's level, and then using a three-dimensional array query algorithm to retrieve the corresponding rollback operation permission range from the dynamic permission matrix, combined with the medical record type identifier. The target rollback status in this rollback request is then verified against the retrieved rollback operation permission range to determine whether the rollback request is within the permission range. The permission verification result is output, and the permission verification result, initiator's identifier, unique identifier of the electronic medical record to be rolled back, and verification time are uploaded to the blockchain for notarization. If the permission verification result fails, the process terminates; if it succeeds, the permission verification result is used as the input for S6.
[0026] Specifically, the multi-level rollback operation for electronic signatures in S6 includes:
[0027] S6.1: Based on the signature chain sequence, the reverse tracing algorithm is used to traverse the signature chain sequence in reverse order of timestamps, starting from the current signature node, to determine the number and order of backtracking nodes that need to be traversed from the current state to the target backtracking state. The current signature node is the signature node where the electronic medical record is currently located, and includes node identifier and timestamp.
[0028] S6.2: Taking the number and order of rollback nodes as input, revoke the electronic signatures of each node in reverse order of the rollback node order. During the revocation process, generate an operation record for the revocation of each node. The record content of each node revocation includes the revocation time, the revoker's identifier, and the node information of the revoked signature.
[0029] S6.3: Based on the signature node information corresponding to the target rollback state and the operation records of all node revocations, retrieve and restore the electronic medical record content of the signature node corresponding to the target rollback state from the medical record version library that pre-stores the electronic medical record content corresponding to each node, and retain the intermediate state records during the revocation process of each node. The intermediate state records include the hash value of the medical record content and the signature chain status in the intermediate state.
[0030] S6.4: Based on the output of the restored electronic medical record content and the target rollback status, update the circulation status of the electronic medical record to the target rollback status and generate a rollback completion identifier. The rollback completion identifier is generated using a universally unique identifier and recorded in the metadata of the electronic medical record.
[0031] Specifically, in S3, when obtaining the electronic medical record file to be processed and the corresponding signature chain information, a signature chain information index is established on the blockchain node. The unique identifier of the electronic medical record to be rolled back is used as the index key to associate the storage location of information such as the signature chain sequence, circulation status, and sensitive field markers. When querying the signature chain information, the corresponding data is located through the index.
[0032] Specifically, the risk assessment and control in S4 includes at least the control of high-frequency rollback operations, the control of rollback operations of overdue archived medical records, and the control of operations involving sensitive fields.
[0033] In step S5, the permission verification result is uploaded to the blockchain for notarization, including: performing hash calculations on the permission verification result, initiator identifier, unique identifier of the electronic medical record to be rolled back, and verification time information to generate a fixed-length hash value as a leaf node; constructing a Merkle tree by calculating the hash value of the parent node level by level; during the blockchain notarization process, encapsulating the root hash value of the Merkle tree and the original information into a transaction object and sending it to each node in the blockchain network; and each node verifying the integrity of the Merkle tree through a consensus mechanism.
[0034] Specifically, the electronic medical record snapshot before rollback in S6 includes the complete medical record content before the rollback operation is executed, the current circulation status, the latest signature information, and the snapshot generation timestamp; the electronic medical record snapshot after rollback includes the complete medical record content after rollback is completed, the target rollback status, the signature information of the corresponding node, and the snapshot generation timestamp. Both snapshots are encrypted using an encryption algorithm.
[0035] Compared with the prior art, the beneficial effects of the present invention are:
[0036] This invention proposes an electronic signature rollback control method. By constructing a dynamic permission matrix that includes physician level, medical record type, and operation permission dimensions, and pre-storing a hierarchical permission table, it can perform precise and detailed permission verification on the operator initiating the electronic signature rollback request based on different dimensions. At the same time, after obtaining the electronic medical record file and signature chain information, a risk pre-check is performed to conduct a comprehensive risk assessment and control of the rollback request, effectively avoiding unauthorized or risky rollback operations and ensuring the security and integrity of electronic medical record data.
[0037] This invention proposes an electronic signature rollback control method. The method uploads the permission verification result to the blockchain for evidence storage. After the permission verification is passed and a multi-level rollback operation is performed, the electronic medical record snapshots, permission records, and operation logs before and after the rollback are synchronized to the blockchain storage. By utilizing the immutable and traceable characteristics of the blockchain, it ensures that every step of the electronic signature rollback operation is traceable, providing a reliable basis for subsequent auditing and traceability, and greatly improving the credibility of the data and the compliance of the operation. Attached Figure Description
[0038] Figure 1 This is a schematic diagram of an electronic signature rollback control method according to the present invention;
[0039] Figure 2 This is a flowchart illustrating the principle of an electronic signature rollback control method according to the present invention.
[0040] Figure 3 This is a flowchart of a multi-level rollback operation for an electronic signature rollback control method according to the present invention. Detailed Implementation
[0041] Example 1:
[0042] Please see Figures 1-2 The present invention provides an embodiment of an electronic signature rollback control method, comprising the following steps:
[0043] S1: Construct a dynamic permission matrix and pre-store a hierarchical permission table, which includes physician level dimension, medical record type dimension and operation permission dimension;
[0044] The physician level dimension includes four levels: resident physician, attending physician, associate chief physician, and chief physician, with each level corresponding to a unique physician level code; the medical record type dimension includes four categories: outpatient medical records, inpatient medical records, emergency medical records, and physical examination reports, with each category corresponding to a unique medical record type code; the operation permission dimension includes four permission levels: allow rollback to any node, allow rollback to the direct superior node, allow viewing only rollback records, and prohibit rollback. The hierarchical permission table is stored in the form of a mapping relationship table between physician level code, medical record type code, and permission level.
[0045] Furthermore, this invention employs a three-dimensional cross-permission mapping method to precisely cross-associate the three dimensions of physician level, medical record type, and operation permissions. For example, resident physicians can only revert outpatient medical records to the direct superior's review node and have no right to modify sensitive fields such as medication dosage in the medical records; while chief physicians can revert inpatient medical records to any historical node and modify some sensitive fields under strict record-keeping conditions. This refined division makes the permission boundaries of physicians at different levels clearly distinguishable, avoiding the risk of misoperation caused by lower-level physicians having excessively high permissions.
[0046] S2: Receive an electronic signature rollback request, wherein the electronic signature rollback request includes the initiator identifier, the target rollback status, and the unique identifier of the electronic medical record to be rolled back;
[0047] Furthermore, in step S2, when receiving an electronic signature rollback request, the initiator's identifier, the target rollback status, and the unique identifier information of the electronic medical record to be rolled back are encrypted using the SSL / TLS encryption protocol. At the same time, a request verification mechanism is set on the server side to perform integrity verification on the received electronic signature rollback request.
[0048] The initiator identifier is a combination of the physician's employee number and the code of the department to which they belong; the target rollback status includes four rollback nodes: draft, awaiting review by a senior physician, awaiting approval by the department head, and completed signature; the unique identifier of the electronic medical record to be rolled back is the hash value of the medical record creation timestamp and the patient's unique identifier.
[0049] It should be emphasized that in this invention, the initiator identifier, target rollback status, and unique medical record identifier included in the rollback request must all conform to a preset format. For example, the physician's employee number must match the alphanumeric rule, and the unique medical record identifier must pass the hash value validity check to prevent illegal format requests from entering the system.
[0050] S3: Based on the unique identifier of the electronic medical record to be rolled back in the rollback request, obtain the electronic medical record file to be processed and the corresponding signature chain information. The electronic medical record file includes medical record content and medical record type identifier. The signature chain information includes signature chain sequence, circulation status, and sensitive field markers.
[0051] In step S3, when obtaining the electronic medical record file to be processed and the corresponding signature chain information, a signature chain information index is established on the blockchain node. The unique identifier of the electronic medical record to be rolled back is used as the index key to associate the storage location of information such as the signature chain sequence, circulation status, and sensitive field markers. When querying the signature chain information, the corresponding data is located through the index.
[0052] The signature chain sequence records the signing flow order of the electronic medical record, the current flow status records the current signing stage of the electronic medical record, and the sensitive fields mark the fields in the medical record content that require special control.
[0053] Furthermore, when acquiring the electronic medical record (EMR) files to be processed and their corresponding signature chain information, for cases where the EMR files are stored in a distributed file system, a caching mechanism is adopted to improve data reading efficiency. A local cache is set up in the EMR management system to cache frequently accessed EMR files. When an EMR file needs to be retrieved, the system first checks whether the file exists in the cache. If it exists, it is read directly from the cache, reducing the number of accesses to the distributed file system. At the same time, a cache update strategy is set up so that when the EMR file changes in the distributed file system, the cache is updated in a timely manner to ensure the consistency between the cached data and the original data.
[0054] S4: Based on the acquired electronic medical record files and signature chain information, perform risk pre-checks and conduct risk assessments and controls on electronic signature rollback requests;
[0055] The risk assessment and control in S4 includes at least the following: control over high-frequency rollback operations, control over rollback operations of overdue archived medical records, and control over operations involving sensitive fields.
[0056] S5: Verify the operation permissions of the operator who initiated the electronic signature rollback request based on the dynamic permission matrix, obtain the permission verification result, and upload the permission verification result to the blockchain for storage;
[0057] Furthermore, uploading the authorization verification result to the blockchain for evidence storage includes: generating a verification record containing the initiator's identifier, the unique identifier of the electronic medical record, the verification result, and the verification time; calculating the hash value of the record; and writing the hash value and the record content together into a new block of the blockchain. The block also includes the hash value of the previous block to ensure the integrity of the chain structure.
[0058] Furthermore, based on historical rollback operation data, the rollback frequency of different physician levels for various types of medical records is calculated using frequency statistics. Combined with a risk assessment model constructed using the analytic hierarchy process, a risk coefficient is generated. The system deeply binds the risk coefficient with permission allocation. For example, for emergency medical records with high-frequency rollback and high risk coefficient, the rollback permissions of lower-level physicians are automatically tightened, requiring real-time approval from a senior physician for their rollback operations. For low-frequency, low-risk physical examination reports, permissions are appropriately relaxed to improve efficiency. After implementation, the rollback anomaly rate of high-risk medical records has been reduced, balancing security and operability.
[0059] S6: If the permission verification result is passed, perform a multi-level rollback operation of the electronic signature according to the target rollback state and the signature chain sequence, backtrack to the signature node corresponding to the target rollback state and restore the electronic medical record content of the node, and after the multi-level rollback operation is completed, synchronize the electronic medical record snapshot before rollback, the electronic medical record snapshot after rollback, the permission records and operation logs involved in this rollback to the blockchain for storage.
[0060] The electronic medical record snapshot before rollback in S6 includes the complete medical record content before the rollback operation, the current circulation status, the latest signature information, and the snapshot generation timestamp; the electronic medical record snapshot after rollback includes the complete medical record content after rollback, the target rollback status, the signature information of the corresponding node, and the snapshot generation timestamp. Both snapshots are encrypted using an encryption algorithm.
[0061] The permission records involved in this rollback include the mapping relationship related to the initiator's permissions in the dynamic permission matrix, the permission level information queried during the permission verification process, and the blockchain storage address of the permission verification result; the operation log includes the initiator identifier, the unique identifier of the electronic medical record, the start time of the rollback operation, the end time of the rollback operation, the list of nodes traversed by the rollback, the revocation time of each node, and the rollback operation result. The operation log is named using a timestamp + serial number format.
[0062] Furthermore, the permission records involved in this rollback include not only the mapping relationship between the initiator's permissions in the dynamic permission matrix, the permission level information queried during the permission verification process, and the blockchain storage address of the permission verification results, but also abnormal information during the permission verification process. When an error occurs during the permission verification process, such as abnormal dynamic permission matrix data or permission verification algorithm execution error, the system automatically records information such as the exception type, exception occurrence time, and exception description. This exception information helps to troubleshoot and optimize the permission verification process in the future, thereby improving the stability and reliability of the permission management system.
[0063] Furthermore, synchronizing the electronic medical record snapshots before and after the rollback, as well as the permission records and operation logs involved in this rollback, to the blockchain for storage includes: calculating the hash values of the snapshots before and after the rollback, the permission records, and the operation logs respectively, generating a summary record containing four hash values and the synchronization time, writing the summary record and its hash value into the blockchain, and simultaneously establishing an association index between the summary record and the evidence storage block of the permission verification results in step S5.
[0064] Simultaneously, when synchronizing the electronic medical record snapshots before and after the rollback, as well as the permission records and operation logs involved in this rollback, to ensure the security and efficiency of cross-chain communication, a cross-chain communication architecture based on a blockchain gateway is adopted. A blockchain gateway is set up between different blockchain systems to be responsible for protocol conversion, data format adaptation, and security verification between different blockchain systems. Through the blockchain gateway, information such as the electronic medical record snapshots before and after the rollback, as well as the permission records and operation logs involved in this rollback, are transmitted from the blockchain system currently used for electronic signature rollback control to the blockchain system for synchronous storage according to the cross-chain communication protocol.
[0065] Furthermore, to improve snapshot generation efficiency and reduce storage costs when generating electronic medical record snapshots before and after rollback, this invention employs differential compression technology. First, the electronic medical record file is divided into blocks, and the hash value of each block is calculated. When generating the snapshot before rollback, a list of hash values for all data blocks and related metadata of the medical record are recorded. When generating the snapshot after rollback, hash value comparison is used to record only the hash values of the changed data blocks and their corresponding metadata changes. Then, the changed data blocks are compressed using a compression algorithm to reduce the storage volume of snapshot data. Simultaneously, when it is necessary to view or restore the snapshot, the changed parts can be quickly located for decompression and processing, improving the efficiency of snapshot management.
[0066] The construction of the dynamic permission matrix includes:
[0067] S1.1: Collect historical rollback operation records, and use frequency statistics combined with a pre-built risk assessment model to statistically analyze the rollback operation frequency and risk coefficient of different physician levels for different types of medical records. The risk assessment model is constructed based on the analytic hierarchy process.
[0068] Furthermore, the specific steps of S1.1 include:
[0069] (1) Extract historical rollback operation records from the operation log database of the hospital's electronic medical record system. The collection period is set to the past year. The operation log must include: the physician's employee number that performed the rollback operation, the unique identifier of the medical record to be rolled back, the time when the rollback operation occurred, the status of the medical record before the rollback, the target status after the rollback, the code that records the reason for the rollback, the medical record fields involved in the rollback operation, and whether the operation was ultimately successful.
[0070] (2) After extracting the above information through the database query function, establish data associations between multiple systems:
[0071] The physician's employee ID is linked to the physician level table in the hospital's human resources system, which maps to four levels: resident physician, attending physician, associate chief physician, and chief physician.
[0072] The unique identifier of a medical record is associated with the classification table of the electronic medical record management system, which is mapped to four categories: outpatient medical records, inpatient medical records, emergency medical records, and physical examination reports.
[0073] The rollback reason code is converted into a standardized description, such as content error, process omission, and permission adjustment, to provide a clear basis for risk assessment;
[0074] (3) Perform data cleaning and anomaly handling on data from multiple systems, including removing duplicate records, handling missing values, correcting logical errors, and standardizing time formats;
[0075] (4) Statistical groups are formed by combining physician level and medical record type, and the total number of rollback operations for each group in the monthly cycle is counted;
[0076] (5) For each group, divide the total number of rollback operations in a month by the number of days in that month to obtain the average number of rollback operations per day for that group, which reflects the rollback intensity of that group;
[0077] (6) Divide the original backoff frequency by the total number of physicians corresponding to the group, and then divide it by the total number of medical records corresponding to the group to obtain the average daily backoff probability of a single physician for a single medical record, i.e., the standardized frequency.
[0078] (7) Establish a hierarchical structure model, which includes a target layer, a criterion layer, and a scheme layer;
[0079] The target layer assesses the risk coefficient of the rollback operation; the criteria layer includes three core risk indicators: first, the impact on the integrity of medical records, i.e., whether the rollback leads to the loss or inconsistency of key medical records; second, the risk of patient privacy leakage, i.e. whether the rollback involves the modification of sensitive fields, such as medical history and ID number; and third, the risk of medical process delay, i.e. whether the rollback leads to the interruption of the diagnosis and treatment process or the delay of the approval process; the solution layer subdivides the rollback operation type according to physician level + medical record type + reason for rollback.
[0080] (8) For the three indicators of the criteria layer, a judgment matrix is formed by comparing the importance of the indicators pairwise. For each operation type of the scheme layer, a judgment matrix is constructed for the three indicators of the criteria layer to reflect the risk level of the operation type under each risk indicator.
[0081] (9) Calculate the largest eigenvalue and the corresponding eigenvector of the judgment matrix, and normalize the eigenvector to obtain the weight of each index or operation type;
[0082] (10) For each rollback operation type, multiply the weights of the three indicators in the criteria layer by the score of the operation type under the corresponding indicator, and then add the three products together to obtain the comprehensive risk score of the operation type.
[0083] (11) Divide the risk score of each operation type by the highest risk score among all operation types to obtain a risk coefficient between 0 and 1. The closer the risk coefficient is to 1, the higher the risk of the operation type.
[0084] (12) The obtained standardized rollback frequency and risk coefficient are grouped and associated by physician level + medical record type to form the rollback operation frequency and corresponding risk coefficient for each group.
[0085] It is important to emphasize that in this invention, based on the frequency statistics and risk assessment model of historical rollback operations, the risk coefficient is incorporated into the permission allocation criteria. For example, for emergency medical records with high frequency of rollbacks and high risk coefficients, the rollback permissions of lower-level physicians are automatically tightened, thereby improving the reliability of medical data.
[0086] S1.2: Based on the statistical results, use the permission mapping algorithm to set the initial permission mapping relationship and form the basic permission table;
[0087] Furthermore, the basic permission table includes a physician level column, a medical record type column, and an operation permission column. The operation permissions are represented in code form, such as 0 indicating no permission, 1 indicating permission to roll back to the direct parent node, and 2 indicating permission to roll back to any node.
[0088] S1.3: Set dynamic permission adjustment rules, and monitor physician level changes and new medical record type events in real time through system monitoring, including:
[0089] When a physician's level changes, a permission update procedure is triggered. The permission update procedure automatically updates the corresponding physician's permission record in the basic permission table according to the pre-set level and permission correspondence rules. When a new medical record type is added, default permissions are automatically assigned to each physician level based on the permission inheritance principle of similar medical record types, and the new permission record is added to the basic permission table.
[0090] The principle of permission inheritance based on similar medical record types means that when a new medical record type is added to the system, it is not necessary to manually configure permissions for each physician level. Instead, by analyzing the similarity of the new medical record type with other existing medical record types in the system in terms of core attributes, the permission allocation rules of the most similar existing medical record type are automatically inherited, thereby generating default permissions for each physician level for the new medical record type.
[0091] For example, when a physician is promoted from a resident physician to an attending physician, their rollback permission for medical record types changes from only allowing rollback to the immediate superior node to allowing rollback to any node.
[0092] Furthermore, the system's monitoring module captures two key events in real time: changes in physician levels and the addition of new medical record types. When a physician's level is upgraded, the system automatically triggers a permission update procedure, expanding the scope of their fallback permissions according to preset level-permission correspondence rules. For example, it upgrades the fallback from only allowing fallback to the immediate superior node to allowing fallback to nodes within three levels. When a new medical record type is added, initial permissions are automatically assigned to physicians of each level based on the principle of permission inheritance for similar medical record types, avoiding the lag and error rate of manual configuration. This dynamic adjustment shortens the permission response time and improves the accuracy of permission configuration.
[0093] S1.4: Integrate the basic permission table with the dynamic adjustment rules to generate a dynamic permission matrix and store it in a distributed database. The distributed database supports real-time read and write operations and permission change synchronization.
[0094] Furthermore, the distributed deployment supports automatic failover for node failures. When a single node fails, the system switches to a backup node within 30 seconds, ensuring uninterrupted access control services. Meanwhile, as the hospital expands, such as by adding branches or departments, seamless expansion can be achieved by adding nodes, with storage capacity and processing power growing linearly to meet long-term business development needs.
[0095] The process of obtaining the electronic medical record file to be processed and the corresponding signature chain information includes:
[0096] S3.1: Use a string parsing algorithm to parse the unique identifier of the electronic medical record to be rolled back and determine the storage path of the electronic medical record;
[0097] Furthermore, the specific steps of S3.1 include:
[0098] (1) Obtain the unique identifier of the electronic medical record to be returned;
[0099] (2) Extract the first two characters of the unique identifier and compare them with the preset electronic medical record. If they do not match, the identifier is determined to be invalid and the exception handling process is triggered. If they match, proceed to the next step of splitting to obtain the unique identifier after removing the fixed prefix.
[0100] (3) After removing the fixed prefix, the unique identifier is split by "-" for the first time to obtain the segmented information string and the check code;
[0101] (4) Split the segmented information string again by “-” to obtain the medical institution code and detailed information string, and obtain the split sub-items;
[0102] (5) Validate each sub-item after splitting according to preset rules:
[0103] (6) Calculate the check value using a preset algorithm and compare it with the split check code. If they match, the identifier is deemed valid; if they do not match, the check code is marked as incorrect and exception handling is triggered.
[0104] In this invention, the preset algorithm adopts the textual description of the modulo-11 algorithm: each character in the segmented information string is converted into a number according to its ASCII code value, the sum is taken and the remainder is divided by 11, and then mapped to the characters 0-9 and A, where A corresponds to 10.
[0105] (7) Standardize the format of fields that pass the validation;
[0106] (8) The system presets the root directory for storing electronic medical records as the starting point of the path;
[0107] (9) Map the parsed fields to the various levels of the path in the hierarchical order of root directory → medical institution code → year → month → patient ID → medical record type → random sequence code;
[0108] (10) Concatenate the directories and file names at each level in hierarchical order to form a complete storage path.
[0109] S3.2: Retrieve the electronic medical record file from the corresponding path in the electronic medical record database. The medical record content includes the patient's basic information, diagnostic records, treatment plans, and examination reports.
[0110] S3.3: Use a unique identifier as the query keyword to query the signature chain information stored in the blockchain. The signature chain sequence records the signer identifier, signature time, and signature type of each signature node in timestamp order.
[0111] S3.4: Extract the current circulation status and sensitive field markers from the signature chain information. The sensitive field markers are implemented using text annotation technology, which is achieved by combining a natural language processing model with a rule engine.
[0112] For example, named entity recognition algorithms are used to identify patient privacy information fields, such as name and ID number, and mark them with red asterisks; for medication dosage fields, they are marked with blue underlines according to pre-set rules, so as to facilitate quick identification and processing in subsequent operations.
[0113] The specific steps of S4 include: based on the signature chain sequence, using a frequency statistics algorithm to count the initiator's rollback frequency within a preset time period, and combining this with a high-frequency rollback threshold to determine whether it is a high-frequency rollback; if it exceeds the high-frequency rollback threshold, it is considered a risk; obtaining the electronic medical record's circulation status from the signature chain information and matching it with a pre-set archiving status judgment rule; if it is in an overdue archiving status, it is considered a risk; identifying content marked with sensitive fields in the electronic medical record file; if the rollback operation involves modification of sensitive fields, it is considered a risk; outputting the risk pre-detection result; if any risk exists, the risk pre-detection result is "fail" and the process is terminated; otherwise, it is "pass" and S5 is executed.
[0114] When analyzing the frequency of rollbacks by the initiator within a preset time period based on the signature chain sequence using a frequency statistics algorithm, it's essential to understand that the signature chain sequence is structured data recording all operations of the electronic medical record in chronological order. Each record contains the following core information: initiator identifier, operation time, operation type, operation object, and operation result. The parsing algorithm first reads each record in the signature chain sequence chronologically, establishing a temporary data list. The operation types include: signature, rollback, view, and modify. The operation object refers to the unique identifier of the medical record being operated on. Therefore, the frequency statistics algorithm for calculating the initiator's rollback frequency within a preset time period based on the signature chain sequence specifically includes:
[0115] (1) From the temporary data list, perform an exact match between the operation initiator identifier and the initiator identifier in the current rollback request to filter out all operation records belonging to that initiator;
[0116] (2) From the subset of initiator operations, further filter the records with the operation type field as rollback, exclude non-rollback operations such as signature and view, and at the same time, verify the operation result field of each rollback operation record, retain only successful rollback operations, and form a list of valid rollback records of the initiator. Among them, only successful rollback operations are retained because failed rollback operations do not have an actual impact on the medical record status and are not included in the statistics.
[0117] (3) Determine the boundaries and duration of the preset time period. The preset time period is preset by the system according to the business scenario or defined by the user. The value is the past 24 hours. The system defaults to taking the current time as the end of the time period and the current time minus the duration of the time period as the start. Iterate through each record in the effective rollback record list of the initiator, extract the operation time field, and compare it with the start and end times of the preset time period:
[0118] If the operation time is between the start time and the end time, it is determined to be a valid rollback operation within the time period and is included in the statistical count;
[0119] If the operation time is earlier than the start time or later than the end time, it is judged as an operation outside the time period and excluded from the statistical scope.
[0120] (4) Count all records of valid rollback operations within the time period and sum them up to obtain the total number of rollback operations initiated by the initiator within the preset time period;
[0121] (5) Determine the duration unit of the time period, and divide the total number of rollback operations within the preset time period by the duration of the time period to obtain the initiator's average daily rollback frequency.
[0122] In step S5, the operation permissions of the operator initiating the electronic signature rollback request are verified based on the dynamic permission matrix to obtain the permission verification result, including:
[0123] A1: Match the physician level corresponding to the initiator identifier with the initiator identifier, and retrieve the corresponding rollback operation permission range from the dynamic permission matrix through a three-dimensional array query algorithm, combined with the medical record type identifier;
[0124] The dynamic permission matrix is stored in a distributed database as a three-dimensional array. The three dimensions are as follows: the first dimension, i.e., rows, represents the physician level, sorted from low to high, namely resident physician, attending physician, associate chief physician, and chief physician; the second dimension, i.e., columns, represents the medical record type, arranged in a preset order, namely outpatient medical record, inpatient medical record, emergency medical record, and physical examination report; the third dimension, i.e., values, represents the scope of rollback operation permissions, represented by a structured string, such as only allowing rollback to the direct parent node, allowing rollback to any node, and prohibiting rollback.
[0125] Furthermore, the specific steps of A1 include:
[0126] (1) Parse the structure of the initiator identifier, where the initiator identifier is a pre-set structured string of the system, which contains core sub-segments that can be used to associate physician information, and the parsing algorithm first splits the identifier according to the delimiter;
[0127] (2) The query level of the associated physician information database includes: performing an exact match query in the database based on the physician employee number obtained after splitting the identifier in (1);
[0128] If a unique record is found, extract the physician level field and verify the effective date of the professional title;
[0129] If multiple records are found, extract the level corresponding to the record with the latest effective date of the professional title;
[0130] If no record is found, the initiator identifier is deemed invalid, triggering the permission verification failure process.
[0131] (3) Extract the medical record type identifier from the electronic medical record file through the file parsing interface, and compare the extracted medical record type identifier with the system's preset medical record type coding dictionary;
[0132] If a matching item exists, it is determined to be a valid type identifier, and the corresponding Chinese name is recorded for subsequent permission matrix queries.
[0133] If no matching item is found, the medical record type is determined to be unknown, the permission query process is terminated, and a permission verification failure result is returned.
[0134] (4) Obtain the dynamic permission matrix and assign a unique numeric index to each value in the first and second dimensions;
[0135] (5) Convert the physician level matched in (2) into the first dimension index using the index-name lookup table;
[0136] (6) Convert the medical record type verified in (3) into a second-dimensional index;
[0137] (7) Using the physician level index as the row coordinate, locate the target row of the array, and in the target row, using the medical record type index as the column coordinate, locate the cell, and then read the permission range string stored in the cell.
[0138] A2: Verify the target rollback status in this rollback request against the scope of rollback operation permissions to determine whether this rollback request is within the permission scope;
[0139] A3: Output the permission verification result and upload the permission verification result, initiator identifier, unique identifier of the electronic medical record to be rolled back, and verification time to the blockchain for evidence storage. If the permission verification result fails, the process is terminated. If it passes, the permission verification result is used as the input of S6.
[0140] In step S5, the permission verification result is uploaded to the blockchain for evidence storage, including:
[0141] B1: The authorization verification result, the initiator's identifier, the unique identifier of the electronic medical record to be rolled back, and the verification time information are hashed to generate a fixed-length hash value as a leaf node. The hash calculation is a prior art in this field and is not an inventive solution of this application, so it will not be described in detail here.
[0142] B2: A Merkle tree is constructed by calculating the hash value of the parent node level by level. The Merkle tree is existing technology in this field and is not an inventive solution of this application. It will not be described in detail here.
[0143] It should be noted that by constructing a Merkle tree from the verification results, initiator identifier, and other information, only the root hash needs to be stored on the blockchain, reducing on-chain storage and supporting rapid verification of the integrity of any information.
[0144] B3: During the blockchain notarization process, the root hash value of the Merkle tree and the original information are encapsulated into a transaction object and sent to each node in the blockchain network.
[0145] B4: Each node verifies the integrity of the Merkle tree through a consensus mechanism.
[0146] Example 2:
[0147] Please see Figure 3 In this embodiment, the multi-level rollback operation for electronic signatures in S6 includes:
[0148] S6.1: Based on the signature chain sequence, use the reverse tracing algorithm to traverse the signature chain sequence in reverse order of timestamps, starting from the current signature node, to determine the number and order of backtracking nodes that need to be traversed from the current state to the target backtracking state. The current signature node is the signature node where the electronic medical record is currently located, which includes a node identifier and a timestamp. For example, by traversing the signature chain sequence array, the timestamp of each node is compared with the timestamp of the target backtracking state to find the path.
[0149] The target rollback state is the state specified in the rollback request, and nodes matching this state must be found in the signature chain sequence, including:
[0150] (1) Traverse all nodes from 0 to n according to the array index, filter the nodes whose node status field is consistent with the target rollback status, and form a candidate target node list;
[0151] (2) If the candidate target node list is empty, that is, the state has never appeared in the signature chain, the target rollback state is determined to be invalid, the rollback operation is terminated and a prompt is returned;
[0152] (3) If there are multiple nodes in the candidate target node list, that is, the same state appears multiple times, take the node with the latest signature timestamp that is earlier than the current node timestamp as the final target node, and ensure that it is the most recent target state before the current node.
[0153] (4) Extract the core information of the target node: target timestamp, target node identifier, and the identifier of the preceding node of the target node.
[0154] Furthermore, the specific steps in S6.1 include:
[0155] (1) Obtain the signature chain sequence and locate the current signature node;
[0156] (2) Set the current trace node as the current signature node, and initialize the rollback node list and node counter, wherein the first element of the initialized rollback node list is the identifier of the current trace node;
[0157] (3) Starting from the current node to be traced, traverse backwards according to the chain relationship from the node identifier to the previous node identifier, that is, trace back from the end of the array to the beginning position, and perform the following operations at each step:
[0158] Extract the identifier of the predecessor node of the current trace node, and find the corresponding predecessor node in the signature chain sequence;
[0159] Add the identifier of the preceding node to the fallback node list;
[0160] Incrementing the node counter by 1 indicates that a node has been traced.
[0161] Compare the state of the previous node with the target rollback state. If they match, stop traversing. If they do not match, update the current trace node to the previous node and repeat the above steps.
[0162] (4) When the traversal stops, all nodes in the backtrack node list except the target node are the nodes that need to be backtracked, and the number of nodes is the value of the node counter. At the same time, the backtracking order is the reverse order of the backtrack node list. Among them, all nodes in the backtrack node list except the target node refer to all intermediate nodes from the current node to the target node.
[0163] S6.2: Taking the number and order of rollback nodes as input, revoke the electronic signatures of each node in reverse order of the rollback node order. During the revocation process, generate an operation record for the revocation of each node. The record content of each node revocation includes the revocation time, the revoker's identifier, and the node information of the revoked signature.
[0164] The reverse order of the rollback nodes refers to starting from the node closest to the target rollback state and proceeding sequentially towards the current signature node.
[0165] The revoker is identified by the operator who initiated the electronic signature rollback request.
[0166] S6.3: Based on the signature node information corresponding to the target rollback state and the operation records of all node revocations, retrieve and restore the electronic medical record content of the signature node corresponding to the target rollback state from the medical record version library that pre-stores the electronic medical record content corresponding to each node, and retain the intermediate state records during the revocation process of each node. The intermediate state records include the hash value of the medical record content and the signature chain status in the intermediate state.
[0167] S6.4: Based on the output of the restored electronic medical record content and the target rollback status, update the circulation status of the electronic medical record to the target rollback status and generate a rollback completion identifier. The rollback completion identifier is generated using a universally unique identifier and recorded in the metadata of the electronic medical record.
[0168] Metadata in electronic medical records refers to the descriptive information contained in the electronic medical record file, which is used to record the basic attributes of the medical record.
[0169] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments under the guidance of the present invention without departing from the spirit and scope of the present invention. All of these variations are within the protection scope of the present invention.
[0170] If the technical solution disclosed herein involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution disclosed herein involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the individual through pop-up information or by asking the individual to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.
Claims
1. An electronic signature rollback control method, characterized in that, include: S1: Construct a dynamic permission matrix and pre-store a hierarchical permission table, which includes physician level dimension, medical record type dimension and operation permission dimension; S2: Receive an electronic signature rollback request, wherein the electronic signature rollback request includes the initiator identifier, the target rollback status, and the unique identifier of the electronic medical record to be rolled back; S3: Based on the unique identifier of the electronic medical record to be rolled back in the rollback request, obtain the electronic medical record file to be processed and the corresponding signature chain information. The electronic medical record file includes medical record content and medical record type identifier. The signature chain information includes signature chain sequence, circulation status, and sensitive field markers. S4: Based on the acquired electronic medical record files and signature chain information, perform risk pre-checks and conduct risk assessments and controls on electronic signature rollback requests; S5: Verify the operation permissions of the operator who initiated the electronic signature rollback request based on the dynamic permission matrix, obtain the permission verification result, and upload the permission verification result to the blockchain for storage; S6: If the permission verification result is passed, perform a multi-level rollback operation of the electronic signature according to the target rollback state and the signature chain sequence, backtrack to the signature node corresponding to the target rollback state and restore the electronic medical record content of the node, and after the multi-level rollback operation is completed, synchronize the electronic medical record snapshot before rollback, the electronic medical record snapshot after rollback, the permission records and operation logs involved in this rollback to the blockchain for storage. The process of obtaining the electronic medical record file to be processed and the corresponding signature chain information includes: S3.1: Use a string parsing algorithm to parse the unique identifier of the electronic medical record to be rolled back and determine the storage path of the electronic medical record; S3.2: Retrieve the electronic medical record file from the corresponding path in the electronic medical record database. The medical record content includes the patient's basic information, diagnostic records, treatment plans, and examination reports. S3.3: Use a unique identifier as the query keyword to query the signature chain information stored in the blockchain. The signature chain sequence records the signer identifier, signature time, and signature type of each signature node in timestamp order. S3.4: Extract the current circulation status and sensitive field markers from the signature chain information. The sensitive field markers are implemented using text annotation technology, which is achieved by combining a natural language processing model with a rule engine. The specific steps of S4 include: based on the signature chain sequence, using a frequency statistics algorithm to count the initiator's rollback frequency within a preset time period, and combining this with a high-frequency rollback threshold to determine whether it is a high-frequency rollback; if it exceeds the high-frequency rollback threshold, it is considered a risk; obtaining the electronic medical record's circulation status from the signature chain information and matching it with a pre-set archiving status judgment rule; if it is in an overdue archiving status, it is considered a risk; identifying the content marked with sensitive fields in the electronic medical record file; if the rollback operation involves modification of sensitive fields, it is considered a risk; outputting the risk pre-detection result; if any risk exists, the risk pre-detection result is "not working" and the process is terminated; otherwise, it is "passing" and S5 is executed. In step S5, the operation permissions of the operator initiating the electronic signature rollback request are verified based on the dynamic permission matrix to obtain the permission verification result, including: The process involves matching the initiator's identifier with the corresponding physician's level, and then using a three-dimensional array query algorithm to retrieve the corresponding rollback operation permission range from the dynamic permission matrix, combined with the medical record type identifier. The target rollback status in this rollback request is then verified against the retrieved rollback operation permission range to determine whether the rollback request is within the permission range. The permission verification result is output, and the permission verification result, initiator's identifier, unique identifier of the electronic medical record to be rolled back, and verification time are uploaded to the blockchain for notarization. If the permission verification result fails, the process terminates; if it succeeds, the permission verification result is used as the input for S6. The multi-level rollback operation for performing electronic signatures includes: S6.1: Based on the signature chain sequence, the reverse tracing algorithm is used to traverse the signature chain sequence in reverse order of timestamps, starting from the current signature node, to determine the number and order of backtracking nodes that need to be traversed from the current state to the target backtracking state. The current signature node is the signature node where the electronic medical record is currently located, and includes node identifier and timestamp. S6.2: Taking the number and order of rollback nodes as input, revoke the electronic signatures of each node in reverse order of the rollback node order. During the revocation process, generate an operation record for the revocation of each node. The record content of each node revocation includes the revocation time, the revoker's identifier, and the node information of the revoked signature. S6.3: Based on the signature node information corresponding to the target rollback state and the operation records of all node revocations, retrieve and restore the electronic medical record content of the signature node corresponding to the target rollback state from the medical record version library that pre-stores the electronic medical record content corresponding to each node, and retain the intermediate state records during the revocation process of each node. The intermediate state records include the hash value of the medical record content and the signature chain status in the intermediate state. S6.4: Based on the output of the restored electronic medical record content and the target rollback status, update the circulation status of the electronic medical record to the target rollback status and generate a rollback completion identifier. The rollback completion identifier is generated using a universally unique identifier and recorded in the metadata of the electronic medical record. Uploading the permission verification result to the blockchain for notarization includes: performing hash calculations on the permission verification result, initiator identifier, unique identifier of the electronic medical record to be rolled back, and verification time information to generate a fixed-length hash value as a leaf node; constructing a Merkle tree by calculating the hash value of the parent node level by level; during the blockchain notarization process, encapsulating the root hash value of the Merkle tree and the original information into a transaction object and sending it to each node in the blockchain network; and verifying the integrity of the Merkle tree through a consensus mechanism.
2. The electronic signature rollback control method as described in claim 1, characterized in that, The construction of the dynamic permission matrix includes: S1.1: Collect historical rollback operation records, and use frequency statistics combined with a pre-built risk assessment model to statistically analyze the rollback operation frequency and risk coefficient of different physician levels for different types of medical records. The risk assessment model is constructed based on the analytic hierarchy process. S1.2: Based on the statistical results, use the permission mapping algorithm to set the initial permission mapping relationship and form the basic permission table; S1.3: Set dynamic permission adjustment rules, and monitor physician level changes and new medical record type events in real time through system monitoring, including: When a physician's level changes, a permission update procedure is triggered. The permission update procedure automatically updates the corresponding physician's permission record in the basic permission table according to the pre-set level and permission correspondence rules. When a new medical record type is added, default permissions are automatically assigned to each physician level based on the permission inheritance principle of similar medical record types, and the new permission record is added to the basic permission table. S1.4: Integrate the basic permission table with the dynamic adjustment rules to generate a dynamic permission matrix and store it in a distributed database. The distributed database supports real-time read and write operations and permission change synchronization.
3. The electronic signature rollback control method as described in claim 2, characterized in that, In step S3, when obtaining the electronic medical record file to be processed and the corresponding signature chain information, a signature chain information index is established on the blockchain node. The unique identifier of the electronic medical record to be rolled back is used as the index key to associate the storage location of information such as the signature chain sequence, circulation status, and sensitive field markers. When querying the signature chain information, the corresponding data is located through the index.
4. The electronic signature rollback control method as described in claim 3, characterized in that, The risk assessment and control in S4 includes at least the control of high-frequency rollback operations, the control of rollback operations for overdue archived medical records, and the control of operations involving sensitive fields.
5. The electronic signature rollback control method as described in claim 4, characterized in that, The electronic medical record snapshot before rollback in S6 includes the complete medical record content before the rollback operation was executed, the current circulation status, the latest signature information, and the snapshot generation timestamp. The rolled-back electronic medical record snapshot includes the complete medical record content after the rollback is completed, the target rollback status, the signature information of the corresponding node, and the snapshot generation timestamp. Both snapshots are encrypted using an encryption algorithm.