Clinical data full-link de-identification flow system

Abstract

This invention belongs to the field of clinical data security technology, specifically a clinical data end-to-end de-identification and transfer system. The anchor point generation module generates a root anchor point identifier when a clinical case is created. This root anchor point identifier remains unchanged from its generation and is unique to all previously generated root anchor point identifiers. It is generated using an independent encoding space separate from the patient's identity information. The attribute tag association module encapsulates clinical attribute information into independent attribute tags and establishes a loosely coupled association with the root anchor point identifier. The state control module determines the visibility state of each attribute tag based on the target scenario and generates attribute mapping configurations. Visibility states include at least push-back and pull-up states. The collaborative scheduling module writes the attribute mapping configurations into data packets and distributes them to the target system. This solution eliminates the point-to-point security risks of centralized mapping forms by loosely associating the pre-generated root anchor point identifier with attribute tags, combined with scenario-based dynamic visibility state management.

Description

Technical Field

[0001] This invention belongs to the field of clinical data security technology, specifically a clinical data end-to-end de-identification and transfer system. Background Technology

[0002] Clinical data is a crucial foundational resource for medical diagnosis, disease research, drug development, and public health governance. During the flow and sharing of clinical data, to prevent the leakage of patient personal information, data de-identification is typically required. This involves replacing or masking information directly linked to specific individuals, such as names and identification numbers, so that the processed data can still be used for analysis and research without revealing the patient's identity. To this end, various technical solutions have been explored, including adding noise to sensitive fields using differential privacy algorithms before data release, or implementing differentiated de-identification strategies based on the visitor's role and business scenario. These approaches are gradually evolving from single-time de-identification and one-off replacement towards dynamic and scenario-based approaches.

[0003] However, existing technical solutions still have room for improvement in practical applications. For example, some solutions replace the patient's original identity information with a temporary identifier generated after desensitization during data de-identification. This temporary identifier is only generated during the desensitization operation and is tightly coupled with the de-identification operation. When data flows across multiple system nodes, the temporary identifiers generated by each system are inconsistent, making it difficult to correctly associate cross-system data for the same patient. In addition, some solutions use a centralized storage mapping table to maintain the correspondence between the original information and the desensitized information. Once this mapping table is illegally accessed, the entire original data can be restored. Furthermore, de-identification in existing technologies is mostly a one-time operation. The original desensitized value is directly replaced or deleted, and the visibility of information cannot be dynamically restored or adjusted according to changes in the flow scenario. The data lacks flexible controllability during the flow process. Therefore, how to build a de-identification flow mechanism in the entire clinical data flow that maintains cross-system data consistency, eliminates single-point security risks, and supports dynamic adjustment of information visibility according to the flow scenario is a direction that those skilled in the art continue to focus on. Summary of the Invention

[0004] To address the problems mentioned in the background section, this invention provides a clinical data end-to-end de-identification transfer system to solve the problem of data association being easily broken due to the coupling of identification and desensitization during system transfer.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a clinical data end-to-end de-identification transfer system, comprising: The anchor point identifier generation module is used to respond to the clinical case creation event and generate a root anchor point identifier for the clinical case. The root anchor point identifier remains unchanged from the time of generation and is not repeated with any of the previously generated root anchor point identifiers. The root anchor point identifier is generated using an independent coding space that is independent of the coding space where the patient's identity information is located. The attribute tag association module is used to obtain multiple clinical attribute information of the clinical case, encapsulate each clinical attribute information into an independent attribute tag, and establish a loosely coupled association relationship between each attribute tag and the root anchor point identifier. The clinical attribute information includes patient identification information, demographic information, and diagnosis and treatment information. The state control module is used to determine the visibility status of each attribute tag in this transfer based on the target scenario of the clinical data to be transferred in the clinical case, and generate the corresponding attribute mapping configuration. The visibility status includes at least a push-back state that is available in plaintext and a pull-up state that is de-identified. The collaborative scheduling module is used to write the attribute mapping configuration into the structured fields of the data packets to be distributed when the clinical data needs to be transferred to the target system, and to distribute the data packets carrying the root anchor identifier and attribute tags in the visibility state specified by the attribute mapping configuration to the target system.

[0006] Optionally, the anchor point identifier generation module includes a timestamp generation unit and a random number generation unit; The timestamp generation unit is used to obtain the time of occurrence of the clinical case creation event and generate a timestamp; The random number generation unit is used to collect physical noise source signals from the hardware environment where the random number generation unit is located, and generate a fixed-length random number string after hashing the collected physical noise source signals; The root anchor identifier is formed by concatenating the timestamp, the system node identifier that runs the anchor identifier generation module, and the random number string. The generation process of the random number string does not use any patient identification information as input.

[0007] Optionally, the operation of the attribute tag association module to obtain the clinical attribute information and encapsulate it into attribute tags takes precedence over any de-identification processing request for the clinical case in terms of time sequence. This operation is triggered by the clinical case creation event and is not triggered by the de-identification processing request.

[0008] Optionally, the state control module includes an encryption processing unit and a metadata retention unit; The encryption processing unit is used to encrypt the plaintext value of an attribute tag when the visibility state of the attribute tag is determined to be the raised state. The metadata retention unit is used to retain the field name, data type, status change timestamp, and key index field of the attribute tag on the root anchor identifier after encryption.

[0009] Optionally, the state control module is further configured to, when the clinical data is switched from the current circulation scenario to a new circulation scenario, if the attribute mapping configuration corresponding to the new circulation scenario indicates that the visibility state of the attribute tag is the pushback state, then decrypt the encryption result of the attribute tag, and the decryption operation directly obtains the key from the key index field carried by the attribute tag itself.

[0010] Optionally, the state control module further includes a mode parameter configuration unit; The mode parameter configuration unit is used to write a de-identification processing mode parameter field for each attribute tag in the attribute mapping configuration. The value of the de-identification processing mode parameter field includes at least a replacement processing mode and a mask processing mode. The attribute tag in the pulled-up state is presented to the outside in the data packet according to the processing mode it points to.

[0011] Optionally, when the de-identification processing mode parameter field of an attribute tag points to the replacement processing mode, the original plaintext value of the attribute tag is replaced with a pseudo-name value that has the same data type and the same format characteristics as the original plaintext value. When the de-identification processing mode parameter field of an attribute tag points to the masked processing mode, the characters in the original plaintext value of the attribute tag corresponding to the high-sensitivity segment are replaced with placeholder characters. The high-sensitivity segment is determined by the preset rule corresponding to the data type of the attribute tag.

[0012] Optionally, when the collaborative scheduling module distributes the data packet to the target system, it serializes the attribute mapping configuration and writes it into the message header of the data packet. After the target system receives the data packet, its local state control module parses the attribute mapping configuration from the message header of the data packet and determines the current visibility status of each attribute tag based on the parsed attribute mapping configuration.

[0013] Optionally, it also includes a status audit module, which is used to record the visibility status change event of each attribute tag in each flow after the attribute mapping configuration takes effect. The visibility status change event includes the visibility status of the attribute tag before the flow and the visibility status after the flow.

[0014] Optionally, the collaborative scheduling module includes a scene parsing unit and a configuration encapsulation unit; The scenario parsing unit is used to obtain the system type identifier of the target system and the business purpose identifier of this transfer, and combine the two into the context information of the target scenario; The configuration encapsulation unit is used to serialize the attribute mapping configuration generated by the state control module into a binary field, and write the binary field into the data packet at a specified offset position before the payload data.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention employs an anchor point generation module to generate a unique and unchanging root anchor point at the time of clinical case creation, independent of the coding space containing patient identity information. This is combined with an attribute tag association module to encapsulate various clinical attribute information into independent attribute tags and establish a loosely coupled association with the root anchor point. This fundamentally severs the dependency between de-identification operations and tag generation. The root anchor point remains unchanged despite subsequent data flow and de-identification operations, ensuring data consistency across systems throughout the entire process. Furthermore, a visibility state management mechanism, including at least pushback and pull-up states, is introduced through a state control module. This evolves the data protection method for attribute tags from traditional irreversible replacement to reversible state switching. The encryption processing unit encrypts the plaintext value when the attribute tag enters the pull-up state, and this encryption is continuously maintained by the metadata retention unit. By attaching field names, data types, state change timestamps, and key index fields, dynamic protection of data is achieved during data flow scenarios, while retaining the ability to directly decrypt and restore attribute tags to the pushback state during scenario switching, completing state restoration without relying on external mapping tables. The attribute mapping configuration is serialized and written into the data packet header by the collaborative scheduling module and distributed to the target system along with the data packet. The target system's local state control module parses the configuration from the message header and determines the visibility status of each attribute tag. The entire process does not initiate call requests to the rule service outside the target system, realizing self-portable policy configuration and closed-loop decision-making, eliminating single-point dependence on centralized rule engines. In conjunction with the state audit module, the state information of each attribute tag before and after the visibility status change is recorded in each flow, forming a complete audit trail throughout the entire chain. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the overall system flow of the present invention; Figure 2 This is a schematic diagram of the internal process of the anchor point identification generation module in this invention; Figure 3 This is a schematic diagram of the internal flow of the state control module in this invention; Figure 4 This is a schematic diagram of the internal process of the collaborative scheduling module in this invention. Detailed Implementation

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

[0018] like Figures 1 to 4 As shown, this invention provides a clinical data end-to-end de-identification and transfer system, comprising: Anchor point identifier generation module 100 is used to respond to clinical case creation events and generate root anchor point identifiers for the clinical case. The root anchor point identifier remains unchanged from the time of generation and is not repeated with all previously generated root anchor point identifiers. The root anchor point identifier is generated using an independent coding space that is independent of the coding space where the patient's identity information is located. The attribute tag association module 200 is used to obtain multiple clinical attribute information of the clinical case, encapsulate each clinical attribute information into an independent attribute tag, and establish a loosely coupled association relationship between each attribute tag and the root anchor point identifier. The clinical attribute information includes patient identification information, demographic information, and diagnosis and treatment information. The state control module 300 is used to determine the visibility status of each attribute tag in this transfer based on the target scenario of the clinical data to be transferred in the clinical case, and generate the corresponding attribute mapping configuration. The visibility status includes at least a push-back state that is available in plaintext and a pull-up state that is de-identified. The collaborative scheduling module 400 is used to write the attribute mapping configuration into the structured field of the data packet to be distributed when the clinical data needs to be transferred to the target system, and to distribute the data packet carrying the root anchor identifier and attribute tags in the visibility state specified by the attribute mapping configuration to the target system.

[0019] Specifically, when a patient's clinical case is created for the first time in the system, the anchor identifier generation module 100 responds to the clinical case creation event and generates a root anchor identifier for that clinical case. This root anchor identifier remains unchanged from the time of its generation, does not change throughout the entire lifecycle of the clinical case, and is unique to each other compared to all other root anchor identifiers already generated in the system. Furthermore, the generation of this root anchor identifier uses an independent encoding space, which is isolated from the encoding space containing the patient's identity information; that is, it is impossible to deduce any patient identity information associated with the clinical case from the value of the root anchor identifier.

[0020] After the root anchor point identifier is generated, the attribute tag association module 200 obtains multiple clinical attribute information for the clinical case. This clinical attribute information includes patient identification information, demographic information, and medical records. Patient identification information includes, for example, name, ID number, and contact number; demographic information includes, for example, age, gender, and place of residence; medical records include, for example, diagnosis results, prescribed medications, and surgical records. The attribute tag association module 200 encapsulates each of these clinical attribute information into an independent attribute tag. Each attribute tag is an independent data structure containing the original plaintext value of the clinical attribute information and descriptive metadata. After encapsulation, the attribute tag association module 200 establishes a loosely coupled association between each attribute tag and the root anchor point identifier.

[0021] This loosely coupled relationship means that each attribute tag is attached to the root anchor identifier through an internal association mapping, but the storage location of each attribute tag and the storage location of the root anchor identifier can be physically located in different security domains. The encryption and decryption operations of each attribute tag can be executed independently without depending on access to the root anchor identifier.

[0022] When clinical data from a clinical case needs to be transferred to the target system, the state control module 300 determines the visibility status of each attribute tag in this transfer based on the target scenario. The target scenario is jointly defined by the type of the target system and the business purpose of this transfer. For example, if the target system is a scientific research data analysis platform and the business purpose is clinical research on diabetes, then a target scenario is constituted. The state control module 300 determines the visibility status of each attribute tag individually, and this visibility status is selected from a set consisting of the push-back state and the pull-up state.

[0023] In this context, the "pushback" state indicates that the original plaintext value of the attribute tag remains available in plaintext during this flow, and the target system can directly read and use the original plaintext value of the attribute tag. The "pull-up" state indicates that the original plaintext value of the attribute tag has undergone de-identification processing during this flow; the target system cannot directly read the original plaintext value of the attribute tag, but instead reads the processed rendered value. After determining the visibility state of each attribute tag, the state control module 300 generates an attribute mapping configuration, which records the visibility state of each attribute tag in this flow.

[0024] After the state control module 300 generates the attribute mapping configuration, the collaborative scheduling module 400 writes this configuration into the structured fields of the data packets to be distributed. These structured fields are located at a specific position in the data packet that distinguishes it from the payload data, and are used by the target system's local state control module for parsing after the data packet arrives at the target system. Then, the collaborative scheduling module 400 distributes the data packets carrying the root anchor identifier and attribute tags indicating the visibility state specified in the attribute mapping configuration to the target system.

[0025] Throughout the aforementioned workflow, the root anchor identifier remains constant throughout the entire process of clinical case creation, attribute tag association, visibility status determination, and data packet distribution. This root anchor identifier ensures that the data of the clinical case in all system nodes across the entire chain is associated through the same root anchor identifier. The visibility status of attribute tags is determined independently based on the target scenario of each workflow. The same attribute tag may be in a "pull-up" state in one workflow and switch to a "push-back" state in the next workflow based on the new target scenario. The de-identification operations in each workflow do not affect each other.

[0026] This embodiment generates a unique and unchanging root anchor identifier independent of the patient's identity information encoding space when a clinical case is created, using the anchor identifier generation module 100. This root anchor identifier, generated by the module, remains unchanged and is independent of the patient's identity information encoding space. Combined with the attribute tag association module 200, clinical attribute information is encapsulated into independent attribute tags and a loosely coupled association is established. This completely decouples the generation timing and encoding mechanism of the root anchor identifier from subsequent de-identification operations. Data for the same clinical case across all systems in the entire process is always associated through the same root anchor identifier, resolving the data association breakage problem caused by the coupling between identifiers and de-identification during cross-system transfers. Simultaneously, the state control module 300 independently determines the visibility state of each attribute tag in each transfer and generates an attribute mapping configuration. The collaborative scheduling module 400 writes the attribute mapping configuration into data packets and distributes them, transforming the de-identification operation from a one-time replacement into a state management system that can dynamically switch based on the transfer scenario. This achieves dynamic control over the visibility of data attribute levels throughout the entire transfer process.

[0027] The storage medium of this embodiment is described below. Those skilled in the art will understand that all or part of the module functions of the system in the above embodiments can be implemented by a program instructing related hardware. This program can be stored in a computer-readable storage medium. When executed, the program includes the functions implemented by the anchor point identification generation module 100, attribute tag association module 200, state control module 300, and cooperative scheduling module 400 in the above embodiments. The storage medium may be, for example, ROM / RAM, magnetic disk, optical disk, etc.

[0028] The anchor point identifier generation module 100 includes a timestamp generation unit 110 and a random number generation unit 120; The timestamp generation unit 110 is used to obtain the occurrence time of the clinical case creation event and generate a timestamp; The random number generation unit 120 is used to collect physical noise source signals from the hardware environment where the random number generation unit 120 is located, and generate a fixed-length random number string after hashing the collected physical noise source signals. The root anchor identifier is formed by concatenating the timestamp, the system node identifier of the anchor identifier generation module 100, and the random number string. The generation process of the random number string does not use any patient identification information as input.

[0029] Specifically, after receiving a trigger signal for a clinical case creation event, the anchor point identifier generation module 100 receives a timestamp carrying the trigger signal, which records the moment the trigger signal was emitted. The timestamp generation unit 110 extracts the timestamp from the trigger signal and converts it into a timestamp. The conversion rule is to start from 00:00:00 on January 1, 1970, and count all the seconds that have elapsed until the time indicated by the time mark.

[0030] Simultaneously with the timestamp generation operation, the random number generation unit 120 begins collecting physical noise source signals from its hardware environment. The target of the physical noise source signal collection is the ring oscillator inside the central processing unit where the random number generation unit 120 resides. This ring oscillator is composed of an odd number of inverters connected end-to-end, and its oscillation frequency continuously shifts slightly due to temperature and voltage fluctuations. The random number generation unit 120 continuously reads the instantaneous oscillation frequency values ​​of the ring oscillator at several consecutive time points; each read value is considered a noise sampling point. Collection continues until a preset number of noise sampling points are accumulated, at which point the collection stops. The sequence formed by arranging these noise sampling points in chronological order of collection time is recorded as the physical noise source signal. .

[0031] The random number generation unit 120 will collect the physical noise source signals. Input a hash function This calculates a random number string of fixed length. The hash calculation process is represented as follows: ; in For hash functions, The signal sequence is a physical noise source. The hash function outputs a random number string. Internally, the input is divided into multiple groups, and each group is subjected to multiple rounds of permutation and compression. If any bit in the output changes, the output will be different. On average, about half of the bits change accordingly. During the hash calculation process, the input... All content is No patient identification information was included in the input.

[0032] Root anchor point marking It is composed of three parts: ; in The timestamp output by timestamp generation unit 110 The system node identifier for the running anchor point identifier generation module 100, The random number string output by the random number generation unit 120, with symbols This indicates a string concatenation operation. During concatenation, the strings will be... Convert to a decimal number string. Preserve its original string form. Convert to hexadecimal number strings, and then... in front, In the middle The subsequent sequences are joined end-to-end, and the resulting splice is the root anchor point identifier. .

[0033] In this embodiment, the timestamp generation unit 110 extracts the timestamp from the trigger signal and converts it into a seconds timestamp calculated from 00:00:00 on January 1, 1970. The random number generation unit 120 collects instantaneous oscillation frequency values ​​at multiple time points from the ring oscillator inside the central processing unit to form a physical noise source signal sequence. Hash function Calculate and obtain a random number string Ultimately by , and The anchor points are assembled in sequence to form the root anchor point markers. And hash function The input is entirely derived from physical noise source signals. It does not contain any patient identification information, thus ensuring the isolation between the root anchor identifier and the encoding space containing patient identification information at the generation algorithm level.

[0034] The operation of the attribute tag association module 200 in acquiring the clinical attribute information and encapsulating it into attribute tags takes precedence over any de-identification processing request for the clinical case in terms of time sequence. This operation is triggered by the clinical case creation event and is not triggered by a de-identification processing request.

[0035] Specifically, the operation of the attribute tag association module 200 to obtain clinical attribute information and encapsulate it into attribute tags is directly triggered by the clinical case creation event.

[0036] When a clinical case creation event occurs in the system, the event signal is simultaneously transmitted to the anchor point identifier generation module 100 and the attribute tag association module 200. Upon receiving the event signal, the attribute tag association module 200 immediately initiates the clinical attribute information acquisition process. The first step of the acquisition process is to extract the case identifier of the clinical case from the clinical case creation event. This case identifier is an internal number assigned to the case by the system when the case is generated. Using this case identifier as an index, the attribute tag association module 200 reads each clinical attribute information item by item from the various business forms storing the original data of the clinical case in the system. These business forms include the patient basic information table, the medical record table, and the treatment record table. Patient identification information and demographic information are read from the patient basic information table, and treatment information is read from the medical record table and the treatment record table. Each piece of clinical attribute information read contains two parts: the field name corresponding to the clinical attribute information and the original plaintext value of the clinical attribute information. For example, the field name is "Name", and the original plaintext value is "Zhang San".

[0037] After obtaining all clinical attribute information, the attribute tag association module 200 performs an encapsulation operation on each piece of clinical attribute information. The encapsulation operation involves the following steps: creating an attribute tag data structure for the clinical attribute information; establishing a plaintext value storage area and a metadata storage area within this attribute tag data structure; writing the original plaintext value of the clinical attribute information into the plaintext value storage area; writing the corresponding field name and data type into the metadata storage area; and reserving a status flag bit within the attribute tag data structure. This status flag bit is used to set the visibility status by the status control module 300 during subsequent processing. When encapsulation is complete, this status flag bit is not written with any value. After encapsulation, the attribute tag association module 200 attaches each attribute tag to the root anchor point identifier of the clinical case. The attachment method is as follows: maintaining a tag index table under the root anchor point identifier; each row of the tag index table records the tag identifier and storage address of an attribute tag; and writing the tag identifier and storage address of the newly encapsulated attribute tag into a row of the tag index table.

[0038] It should be noted that the entire acquisition and encapsulation operation described above precedes any de-identification processing request for that clinical case in chronological order. Specifically, the clinical case creation event occurs before the generation of the de-identification processing request. The activation of the attribute tag association module 200 is triggered by the clinical case creation event, but this activation does not depend on the arrival of the de-identification processing request, nor does it use the de-identification processing request as a triggering condition. Even if a clinical case is never requested for de-identification processing throughout its entire lifecycle, the attribute tag association module 200 will still complete the above acquisition and encapsulation operations when the clinical case is created.

[0039] In this embodiment, the attribute tag association module 200 is directly triggered by the clinical case creation event. It immediately reads various clinical attribute information from the patient basic information table, medical record table, and treatment record table using the case identifier as an index. It encapsulates the field name, data type, and original plaintext value of each clinical attribute information into an attribute tag data structure containing a plaintext value storage area, a metadata storage area, and a status flag bit. Then, it writes the tag identifier and storage address of each attribute tag into the tag index table under the root anchor identifier. The entire acquisition and encapsulation operation precedes any de-identification processing request in time sequence, making the establishment of attribute tags independent of whether de-identification processing is performed subsequently. From the perspective of timing and triggering mechanism, it ensures that the association between the root anchor identifier and the attribute tag does not depend on the de-identification processing operation.

[0040] The state control module 300 includes an encryption processing unit 310 and a metadata retention unit 320; The encryption processing unit 310 is used to encrypt the plaintext value of an attribute tag when the visibility state of the attribute tag is determined to be the raised state. The metadata retention unit 320 is used to retain the field name, data type, status change timestamp, and key index field of the attribute tag on the root anchor identifier after encryption.

[0041] Specifically, after receiving the target scene information from the collaborative scheduling module 400, the state control module 300 begins generating attribute mapping configurations for this workflow. The state control module 300 iterates through each attribute tag of the clinical case, determining the visibility state that each attribute tag should be in during this workflow. The determination method is as follows: using the scene identifier of the target scene and the data type of the attribute tag, the corresponding visibility state setting value is retrieved from the pre-configured scene strategy table.

[0042] When the matching query result for a certain attribute tag is in a raised state, the encryption processing unit 310 initiates the encryption operation for that attribute tag. The encryption processing unit 310 first obtains the encryption key corresponding to the target scenario from the key management component. The key is retrieved by using the scene identifier of the target scene as an index to search the key management component. Then, the encryption processing unit 310 reads the original plaintext value stored in the plaintext value storage area of ​​the attribute tag. Using encryption keys right The encryption operation is performed, and the operation process is represented as follows: ; in For attribute tags The original plaintext value, For the encryption key corresponding to the target scenario, It is a symmetric block encryption function. This is the ciphertext value obtained after encryption. The specific process of encryption is as follows: ... The data is divided into multiple groups, and each group undergoes multiple rounds of substitution and permutation operations. In each round, the group is XORed with the corresponding subkey and subjected to a non-linear substitution. The final output is a ciphertext group, and the concatenation of all ciphertext groups is the ciphertext value. After encryption is completed, the encryption processing unit 310 will... Write back to the plaintext value storage area of ​​the attribute tag, overwriting the original plaintext value. .

[0043] Simultaneously with the encryption operation, the metadata retention unit 320 processes the metadata of the attribute tag. The metadata retention unit 320 extracts the field names and data types of the attribute tag from its metadata storage area and obtains the current system time as the timestamp of the attribute tag's state change. This process generates the key index field for that attribute tag. The key index field is generated by taking the encryption key... Index number in the key management component This is used as the value of the key index field. Subsequently, the metadata retention unit 320 stores the field name, data type, and status change timestamp of this attribute label. and key index field Four pieces of information constitute a metadata record. This metadata record is written to the storage location corresponding to the attribute tag in the tag index table associated with the root anchor point identifier, and the status flag bit of the attribute tag is updated to a value indicating the pulled-up state.

[0044] In this embodiment, when the state control module 300 determines that the visibility state of a certain attribute tag is in the raised state based on the target scene matching query, the encryption processing unit 310 retrieves the encryption key from the key management component using the scene identifier of the target scene. The original plaintext value of the attribute tag Symmetric block encryption function Calculate the ciphertext value The data is overwritten and written to the storage area. The metadata retention unit 320 synchronously extracts the field names and data types, and obtains the status change timestamps. Generate key index field The four pieces of information are combined to form a metadata record, which is written into the tag index table associated with the root anchor point identifier. The status flag is updated to the pulled state, so that the original plaintext value of the attribute tag in the pulled state is stored in ciphertext form while the metadata is completely preserved and attached to the root anchor point identifier.

[0045] The state control module 300 is further configured to, when the clinical data is switched from the current circulation scenario to a new circulation scenario, if the attribute mapping configuration corresponding to the new circulation scenario indicates that the visibility state of the attribute tag is the pushback state, then decrypt the encryption result of the attribute tag, and the decryption operation directly obtains the key from the key index field carried by the attribute tag itself.

[0046] Specifically, when a set of clinical data, after completing one round of transfer, is requested to undergo a new round of transfer to another target system based on business needs, the state control module 300 receives the target scenario information for this new round of transfer and begins generating a new attribute mapping configuration for it. The state control module 300 iterates through each attribute tag of the clinical case, matching and querying the scenario strategy table with the scenario identifier of the new target scenario and the data type of each attribute tag to determine the visibility state that each attribute tag should be in during the new round of transfer.

[0047] For a specific attribute label, the state control module 300 performs the following state transition determination: ; in Represents attribute tags Current visibility state This indicates the visibility state that the attribute tag should be in the new target scenario. Indicates the pulled-up state. Indicates the pushback state. This indicates that a decryption operation will be performed. This indicates that decryption will be skipped.

[0048] When the judgment result is When the time comes, the state control module 300 initiates the decryption operation for the attribute tag. The state control module 300 reads the current value of the status flag bit of the attribute tag, confirms that the current value indicates the pull-up state, and then reads the value of the key index field from the metadata record of the attribute tag. The status control module 300 will... Send to the key management component, the key management component according to Retrieve the corresponding decryption key from its internally stored key list. The retrieval process is represented as follows: ; in This represents the retrieval function of the key management component. For the value of the key index field, This is the decryption key that was retrieved.

[0049] The status control module 300 uses a decryption key. The ciphertext value currently stored in the plaintext value storage area for this attribute tag Perform the decryption operation: ; in For attribute tags The ciphertext value, This is the decryption key retrieved based on the key index field. For encryption functions The corresponding decryption function, This is the original plaintext value obtained after decryption and recovery. The specific process of decryption is the inverse process of encryption: [The text abruptly ends here, likely due to an incomplete translation or source material.] Divide the text into multiple ciphertext blocks. For each ciphertext block, perform reverse substitution and reverse permutation operations in reverse order using the same subkey as during encryption. Output plaintext blocks. The concatenation of all plaintext blocks yields the original plaintext value. .

[0050] After decryption is complete, the status control module 300 will... Write back to the plaintext value storage area of ​​the attribute tag, overwriting the original ciphertext value. Update the status flag of the attribute label to a value indicating the pushback state, and update the status change timestamp in the metadata record of the attribute label to the current system time.

[0051] In this embodiment, after determining that decryption is required through state transition judgment, the state control module 300 reads the key index field from the attribute tag's own metadata record. The decryption key was obtained by retrieving it through the key management component. ,use For ciphertext value Decryption function Calculate and recover the original plaintext value It is then written back to the storage area, the status flag is updated to the pushback state, and the status change timestamp is refreshed. The key retrieval for the entire decryption process relies entirely on the key index field carried by the attribute tag itself.

[0052] The state control module 300 also includes a mode parameter configuration unit 330; The mode parameter configuration unit 330 is used to write a de-identification processing mode parameter field for each attribute tag in the attribute mapping configuration. The value of the de-identification processing mode parameter field includes at least a replacement processing mode and a mask processing mode. The attribute tag in the pulled-up state is presented to the outside in the data packet according to the processing mode it points to.

[0053] Specifically, during the generation of the attribute mapping configuration, whenever the visibility state of an attribute tag is determined, the mode parameter configuration unit 330 writes the de-identification processing mode parameter field for that attribute tag in the attribute mapping configuration.

[0054] The de-identification processing mode parameter field written by mode parameter configuration unit 330 is an integer value. This integer value is determined as follows: ; in Represents attribute tags Data types, Indicates the target scene identifier. This represents the composite index lookup function for the schema definition table. This is the value of the de-identification processing mode parameter field to be written. The mode definition table is stored inside the state control module 300, recording the mapping entries from each integer value to the processing mode: integer value 1 maps to the replacement processing mode, integer value 2 maps to the masked processing mode, and integer values ​​3 and above map to other processing modes. Function The execution process is as follows: and As a composite index, the corresponding integer value is searched in the schema definition table, and the found integer value is used as... The value of .

[0055] for This refers to attribute tags that point to a substitution processing mode. When these tags are presented externally in a data packet, their encrypted values ​​are replaced with pseudo-name values. The generation process is as follows: the mode parameter configuration unit 330 uses the original plaintext value of the attribute label. As input, search for the corresponding value replacement table in the replacement processing mode. For matched entries, the value replacement table is a pre-built mapping table that stores multiple correspondences between original values ​​and pseudo-name values. After finding a matching entry, its pseudo-name value is used as the pseudo-name value. Output. The output is... In terms of data type and format characteristics, Maintain consistency.

[0056] for This refers to the attribute tag that points to the masked processing mode. When presented externally in the data packet, some characters in the ciphertext value of this attribute tag are replaced by placeholder characters. The mode parameter configuration unit 330 configures according to... Determine the starting position and length of the highly sensitive segment to be replaced, as well as the placeholder characters used for replacement. This determination is based on a segment definition table and a placeholder character table. The segment definition table stores the starting positions of the segments to be masked corresponding to each data type. and length The placeholder character table stores the placeholder characters corresponding to each data type. The mode parameter configuration unit 330 extracts the attribute tag ciphertext value from position […]. Start, length is Replace all consecutive characters with The characters in the remaining positions remain unchanged. The replacement operation only modifies the value of the attribute tag presented externally in the data packet, and does not change the ciphertext value and metadata record of the attribute tag stored in the status control module 300.

[0057] In this embodiment, the mode parameter configuration unit 330 uses the data type of the attribute tag and the scene identifier of the target scene as a joint index to search and determine the value of the de-identification processing mode parameter field from the mode definition table. Different values ​​point to the replacement processing mode and the mask processing mode, respectively. Each attribute tag in the pulled state presents different types of de-identification results in the data packet according to its own processing mode. The processing modes of each attribute tag are independent of each other and can be configured separately.

[0058] When the de-identification processing mode parameter field of an attribute tag points to the replacement processing mode, the original plaintext value of the attribute tag is replaced with a pseudo-name value that has the same data type and the same format characteristics as the original plaintext value. When the de-identification processing mode parameter field of an attribute tag points to the masked processing mode, the characters in the original plaintext value of the attribute tag corresponding to the high-sensitivity segment are replaced with placeholder characters. The high-sensitivity segment is determined by the preset rule corresponding to the data type of the attribute tag.

[0059] Specifically, when the mode parameter configuration unit 330 of the state control module 300 writes the de-identification processing mode parameter field for an attribute label in the attribute mapping configuration, the collaborative scheduling module 400, when constructing the data packet to be distributed, determines the specific form in which the attribute label is presented in the data packet based on the value of the de-identification processing mode parameter field of the attribute label.

[0060] When the value of the de-identification processing mode parameter field of an attribute tag is 1, indicating a replacement processing mode, the mode parameter configuration unit 330 performs replacement processing on that attribute tag. The first step of replacement processing is to determine the data type of the attribute tag. The data type is given by the data type field stored in the attribute tag's metadata record. Common data types include name, ID number, phone number, address, and diagnosis. The second step is to load the replacement mapping table corresponding to the determined data type from the value replacement table maintained internally by the mode parameter configuration unit 330. This value replacement table is stored in partitions according to data type, with each partition containing multiple mapping records. Each mapping record contains an original value and a pseudo-name value.

[0061] The mode parameter configuration unit 330 reads the original plaintext value of the attribute label. Search the replacement mapping table corresponding to this data type for the original value and... A complete match mapping record. The matching search uses a full string comparison method. The pseudoname is compared character by character with the original value of each mapping record in the replacement mapping table. A successful match is achieved when all characters match. After finding a matching record, the pseudoname value in that matching record is used as the pseudoname value. Output: Pseudo-name value The data type and format characteristics of the original plaintext value The values ​​must be consistent. For example, if the original plaintext value is a three-character Chinese name, the pseudo-name value will also be a three-character Chinese name. If the original plaintext value is an 18-digit ID number, the pseudo-name value will also be an 18-digit number. After the replacement, the value displayed by this attribute tag in the data packet will be consistent. However, within the state control module 300, the plaintext value of this attribute tag is still stored in its storage area. The metadata records remain unchanged.

[0062] When the value of the de-identification processing mode parameter field of an attribute tag is 2, indicating a masked processing mode, the mode parameter configuration unit 330 performs masked processing on that attribute tag. The first step of masked processing is also to determine the data type of the attribute tag. The second step is to load the mask parameter corresponding to the determined data type from the segment definition table and placeholder character table maintained internally by the mode parameter configuration unit 330.

[0063] The segment definition table specifies the character segments that require masking for each data type. These segments are defined by their starting positions. and length Two parameters are defined. Starting position. This indicates the starting character position of the mask from the original plaintext value of the attribute tag, and its length. This indicates how many consecutive characters, starting from the beginning, need to be masked. The segment definition table specifies the number of characters to be masked for different data types. Value and The values ​​are different. For example, for the ID card number type, the segment definition table specifies... , This indicates that the first 8 digits of the ID number, starting from the 7th digit, need to be masked. For telephone numbers, the area code definition table specifies... , This indicates that the first four digits of the phone number, starting from the fourth digit, need to be masked. For name types, the area code definition table specifies... , This indicates that one consecutive Chinese character starting from the second character of the name needs to be masked.

[0064] The placeholder character table specifies the placeholder characters used to replace characters within the masked segment for each data type. Different data types can use the same placeholder characters or different placeholder characters. For example, the placeholder character for ID card number and phone number types is an asterisk, the placeholder character for name type is an asterisk, and the placeholder character for the province, city, and district part of the address type is an empty character, which is omitted directly.

[0065] The mode parameter configuration unit 330 reads the original plaintext value of the attribute label. ,Will Treat it as a character sequence, starting from position Start, length is Replace all consecutive characters with The mathematical expression for the replacement operation is: Let the original plaintext value be... Depend on Composed of 1 character, denoted as The rendered value after masking operation Determined by the following rules: For the first If characters, Then the character at that position is replaced with Otherwise, retain the original characters. After masking is completed, the value of this attribute tag in the data packet will be displayed externally. However, within the state control module 300, the plaintext value of this attribute tag is still stored in its storage area. The metadata records remain unchanged.

[0066] In this embodiment, when the de-identification processing mode parameter field of an attribute tag points to the replacement processing mode, the mode parameter configuration unit 330 uses the original plaintext value of the attribute tag. Perform a string exact match search in the replacement mapping table corresponding to this data type, and take the matched pseudo-name value as the pseudo-name value. The output pseudo-name value is consistent with the original plaintext value in terms of data type and format characteristics; when pointing to the masked processing mode, the mode parameter configuration unit 330 obtains the starting position from the segment definition table according to the data type of the attribute label. and length Retrieve placeholder characters from the placeholder character table ,Will From the middle Starting from the continuous Replace the bit character with Get the rendering value The range of the mask segment is entirely determined by the preset rules corresponding to the data type of the attribute tag. Different types correspond to different mask segments and placeholder characters. The replacement operation only changes the externally presented value in the data packet without changing the internally stored ciphertext value and metadata.

[0067] When the collaborative scheduling module 400 distributes the data packet to the target system, it serializes the attribute mapping configuration and writes it into the message header of the data packet. After the target system receives the data packet, its local state control module parses the attribute mapping configuration from the message header of the data packet and determines the current visibility status of each attribute tag based on the parsed attribute mapping configuration.

[0068] Specifically, after the state control module 300 completes the generation of the attribute mapping configuration, the collaborative scheduling module 400 begins to perform data packet distribution preparation work. The collaborative scheduling module 400 first obtains the attribute mapping configuration generated for this flow from the state control module 300. This attribute mapping configuration is a structured data record that contains the tag identifiers of all attribute tags involved in this flow, as well as the visibility status setting value and the value of the de-identification processing mode parameter field corresponding to each attribute tag.

[0069] The collaborative scheduling module 400 performs a serialization operation on the acquired attribute mapping configuration. The serialization process involves converting each field in the attribute mapping configuration into a binary representation according to a predefined data packet structure. The predefined data packet structure specifies the binary arrangement format of the serialized attribute mapping configuration, which includes an attribute count field and a variable-length record sequence. The attribute count field occupies 4 bytes and stores the total number of attribute tags involved in this transfer. Following the attribute count field is Each attribute configuration record occupies 12 bytes. The first 8 bytes store the attribute tag identifier, the 9th byte stores the visibility status setting of the attribute tag, the 10th byte stores the value of the de-identification processing mode parameter field of the attribute tag, and the 11th and 12th bytes are reserved fields. The serialization operation writes the values ​​of the above fields byte-by-byte into a contiguous binary buffer. All bytes in this buffer constitute the serialized binary field.

[0070] After serialization, the collaborative scheduling module 400 writes the binary field into the message header of the data packet to be distributed. The overall structure of the data packet is: message header first, payload data second. The message header is divided into several fixed-purpose fields, including a data packet type field, a version number field, a message header length field, and an extension header field. The collaborative scheduling module 400 writes the serialized binary field into the extension header field by copying all bytes of the binary field sequentially to the storage area of ​​the extension header field, and synchronously updates the value of the message header length field so that the value of the message header length field is equal to the original message header length plus the sum of the byte length of the binary field. The payload data is then written sequentially to the external presentation values ​​of each attribute tag in its respective visibility state during this flow, with the external presentation values ​​of each attribute tag separated by a predetermined delimiter.

[0071] After completing the message header and payload data writing, the collaborative scheduling module 400 distributes the data packet to the target system through the network transmission channel. Upon receiving the data packet, the target system first reads the value of the message header length field from the message header to determine the total length of the message header. Then, based on the message header length, it locates the starting position of the extension header field and extracts the serialized attribute mapping configuration binary field from the extension header field.

[0072] The target system's local state control module performs a deserialization operation on this binary field. The deserialization operation is the reverse of the serialization operation: first, the first 4 bytes of the attribute count field are read to obtain the total number of attribute tags. Then read the subsequent ones in sequence. Each attribute configuration record is parsed to extract the attribute tag identifier, visibility status setting value, and de-identification processing mode parameter field value. After deserialization, the target system's local state control module obtains configuration information that is completely consistent with the attribute mapping configuration content generated by the source system's state control module 300.

[0073] The target system's local state control module determines the current visibility state of each attribute tag in the data packet based on the attribute mapping configuration obtained from deserialization. For each attribute tag, the target system's local state control module reads the visibility state setting value corresponding to that attribute tag from the attribute mapping configuration. If the setting value is in the push-back state, the attribute tag is available in plaintext form in the target system. If the setting value is in the pull-up state, the attribute tag is presented externally in the target system according to the processing mode pointed to by the de-identification processing mode parameter field.

[0074] It should be noted that from the moment the target system receives the data packet until the target system's local state control module determines the current visibility status of each attribute tag, the entire process is completed locally on the target system. When the target system's local state control module performs the above operations, it reads the attribute mapping configuration already carried in the data packet header and does not need to initiate any call requests to any rule service outside the target system.

[0075] In this embodiment, the collaborative scheduling module 400 serializes the attribute mapping configuration generated by the state control module 300 into binary fields according to the predefined data packet structure definition, writes it into the extended header field of the data packet message header and updates the message header length field, and distributes it to the target system along with the payload data through the network transmission channel. After receiving the data packet, the target system extracts the binary field from the message header extended header field, restores the attribute configuration records one by one through the deserialization operation, and the local state control module of the target system determines the current visibility status of each attribute tag based on the restored attribute mapping configuration. The entire process, from the serialization of the attribute mapping configuration, message header writing, network distribution, message header parsing to deserialization and status determination, is completed in a closed loop locally on the target system without initiating any calls to the rule service outside the target system.

[0076] It also includes a status audit module 500, which is used to record the visibility status change event of each attribute tag in each flow after the attribute mapping configuration takes effect. The visibility status change event includes the visibility status of the attribute tag before the flow and the visibility status after the flow.

[0077] Specifically, the status audit module 500 initiates audit logging operations after the attribute mapping configuration takes effect for each flow. The moment when the attribute mapping configuration takes effect refers to the moment when the collaborative scheduling module 400 completes the distribution of data packets to the target system, and the target system's local status control module determines the visibility status of each attribute tag based on the attribute mapping configuration and returns an acknowledgment signal. The status audit module 500 listens for flow completion notifications from the collaborative scheduling module 400, which carry the flow identifier, target scenario identifier, and the total number of attribute tags involved in this flow.

[0078] After receiving the workflow completion notification, the state audit module 500 extracts the workflow identifier and scene identifier from the notification. Then, using the workflow identifier as an index, it requests the state control module 300 to retrieve the generation record of the attribute mapping configuration corresponding to this workflow. When generating the attribute mapping configuration, the state control module 300 has already saved the visibility state snapshot of each attribute tag before this workflow and the visibility state setting value determined during this workflow in its internal state change cache. Upon receiving the request from the state audit module 500, the state control module 300 returns all records in the cache corresponding to the workflow identifier to the state audit module 500. The returned records include the tag identifier of each attribute tag involved in this workflow, the visibility state value before the workflow, and the visibility state value after the workflow.

[0079] The status audit module 500 iterates through each attribute tag in the returned records, constructing a visibility status change event for each attribute tag. A visibility status change event is a structured data entry containing the following fields: the flow identifier for this flow, the tag identifier for this attribute tag, the visibility status of this attribute tag before this flow, the visibility status of this attribute tag after this flow, the target scenario identifier for this flow, and the timestamp for when the attribute mapping configuration took effect. The sources of each field are as follows: the flow identifier is taken from the flow completion notification; the tag identifier is taken from the record returned by the status control module 300; the states before and after the flow are taken from the corresponding state values ​​in the record; the target scenario identifier is taken from the flow completion notification; and the effective timestamp is taken from the current system clock reading of the status audit module 500.

[0080] When constructing the visibility state change event for each attribute tag, the state audit module 500 enumerates and maps the visibility state values. Visibility states are stored internally as integer values. When constructing the change event, the state audit module 500 converts these integer values ​​into readable state names. The correspondence between integer values ​​and state names is: 0 corresponds to the pushback state, and 1 corresponds to the pull-up state. The state audit module 500 writes the converted state names into the pre-transition state field and the post-transition state field of the change event.

[0081] The state audit module 500 aggregates all completed visibility state change events into a single audit record. This audit record uses the current flow identifier as a unique index, and within the record body, each visibility state change event is arranged in ascending order according to its attribute tag identifier. The state audit module 500 writes this audit record to the audit log storage area, a persistent storage space that appends to the end of the storage area during writing; it cannot be overwritten or deleted. After writing is complete, the state audit module 500 returns an audit record write confirmation to the coordination scheduling module 400.

[0082] The audit records stored in the audit log storage area can be used for subsequent workflow tracing. When it is necessary to trace the visibility status change trajectory of a certain attribute tag in each workflow, the tag identifier of that attribute tag is used to search in the audit log storage area. The search method is to traverse the visibility status change events in each audit record, match the tag identifier field, and sort all the matching change events according to the effective timestamp of the audit record to obtain the complete status change sequence of that attribute tag.

[0083] In this embodiment, after the attribute mapping configuration of each flow takes effect, the status audit module 500 obtains the flow completion notification from the collaborative scheduling module 400 and obtains the visibility status values ​​of each attribute tag involved in this flow before and after the flow from the status control module 300. It constructs a visibility status change event item by item, including flow identifier, tag identifier, state before and after flow, scene identifier and effective timestamp. It collects and forms an audit record indexed by the flow identifier and appends it to the non-overwhelmable audit log storage area, so that the visibility status change of each attribute tag in each flow is traceable, forming a complete audit clue that runs through all flows in the entire chain.

[0084] The collaborative scheduling module 400 includes a scene parsing unit 410 and a configuration encapsulation unit 420; The scenario parsing unit 410 is used to obtain the system type identifier of the target system and the business purpose identifier of this transfer, and combine the two into the context information of the target scenario; The configuration encapsulation unit 420 is used to serialize the attribute mapping configuration generated by the state control module 300 into a binary field, and write the binary field into the data packet at a specified offset position before the payload data.

[0085] Specifically, when the collaborative scheduling module 400 initiates a clinical data transfer, the scenario parsing unit 410 first obtains the context information of the target scenario. The scenario parsing unit 410 obtains the context information from the transfer request received by the collaborative scheduling module 400. This transfer request is issued by the data user system and carries at least two fields: the system type identifier of the target system and the business purpose identifier of this transfer.

[0086] The system type identifier is a system classification code pre-registered in the end-to-end de-identification circulation system for clinical data. Different target systems are assigned a unique system type identifier during registration. For example, the system type identifier for a research data analysis platform is SYS_RESEARCH, the system type identifier for a clinical auxiliary diagnosis and treatment system is SYS_CLINICAL, and the system type identifier for a public health monitoring system is SYS_PUBLIC. The business purpose identifier is a pre-defined business classification code. Different business purposes correspond to different codes. For example, the business purpose identifier for diabetes clinical research is PUR_DIABETES_RESEARCH, the business purpose identifier for multi-center collaborative diagnosis and treatment is PUR_MULTI_DIAGNOSIS, and the business purpose identifier for medical insurance review is PUR_INSURANCE_AUDIT.

[0087] The scenario parsing unit 410 extracts the system type identifier field and the business purpose identifier field from the flow request, and combines the two fields to generate the context information of the target scenario. The combination method is string concatenation, specifically, the system type identifier string and the business purpose identifier string are connected with an underscore character to form a combined string. For example, if the system type identifier is SYS_RESEARCH and the business purpose identifier is PUR_DIABETES_RESEARCH, then the combined string is SYS_RESEARCH_PUR_DIABETES_RESEARCH. This combined string is the context information of the target scenario, and this context information is passed as a whole to the state control module 300, so that the state control module 300 can match and query the visibility status of each attribute tag from the scenario policy table.

[0088] After the state control module 300 completes the generation of the attribute mapping configuration, the configuration encapsulation unit 420 performs a serialization operation on the attribute mapping configuration. The specific process of the serialization operation is as follows: The configuration encapsulation unit 420 first reads the attribute mapping configuration generated by the state control module 300. The attribute mapping configuration contains a total number of attribute tags and an equal number of attribute configuration entries. Each entry contains the tag identifier of the attribute tag, the visibility state setting value, and the value of the de-identification processing mode parameter field.

[0089] The configuration encapsulation unit 420 performs serialization according to a predefined data packet structure definition. This data packet structure definition specifies the binary serialization format of the attribute mapping configuration: bytes 1 to 4 store the total number of attribute tags N, which is a 32-bit unsigned integer in big-endian byte order; starting from byte 5, each 12 bytes stores an attribute configuration entry, where bytes 5 to 12 store the tag identifier, which is a 64-bit unsigned integer; byte 13 stores the visibility status setting value, which is an 8-bit unsigned integer; byte 14 stores the value of the de-identification processing mode parameter field, which is an 8-bit unsigned integer; bytes 15 and 16 are reserved fields, filled with 0x00.

[0090] The configuration encapsulation unit 420 writes the values ​​of the above fields byte by byte into a continuous binary buffer. The writing process is as follows: first, the 4 bytes of N are written to positions 0 to 3 in the buffer. Then, for the first attribute configuration entry, the 8 bytes of its tag identifier are written to positions 4 to 11, the visibility status setting value is written to position 12, the value of the de-identification processing mode parameter field is written to position 13, and the two reserved bytes 0x00 are written to positions 14 and 15. Next, for the second attribute configuration entry, the bytes are written to positions 16 to 27, and so on, until all N entries are written. The total length of the binary buffer is 4 plus 12 multiplied by N bytes.

[0091] After serialization, the configuration encapsulation unit 420 writes the binary field into the data packet at a specified offset position before the payload data. The overall structure of the data packet, starting from the beginning, is as follows: data packet type field (2 bytes), version number field (1 byte), message header length field (2 bytes), extension header length field (2 bytes), extension header field (variable length), and payload data (variable length). This specified offset position is the starting position of the extension header field, and the offset of this starting position relative to the start position of the data packet is 7 bytes, which is the sum of the lengths of the data packet type field, version number field, message header length field, and extension header length field.

[0092] The configuration encapsulation unit 420 writes all bytes of the serialized binary field into the memory area starting at offset 7 of the data packet. The number of bytes written is equal to the length of the binary field. After writing, the configuration encapsulation unit 420 calculates the byte length of the binary field and writes this length value into the extension header length field of the data packet, which is located at offset 5 of the data packet, occupying 2 bytes. At the same time, the configuration encapsulation unit 420 updates the value of the message header length field, which is located at offset 3 of the data packet. Its value is equal to the value of the extension header length field plus 7, that is, the total number of bytes in the message header is 7 plus the extension header length.

[0093] In this embodiment, the scenario parsing unit 410 extracts the system type identifier and business purpose identifier from the flow request, connects the two with underscores to form a context information string of the target scenario, which is then used by the state control module 300 for scenario policy matching. The configuration encapsulation unit 420 serializes the attribute mapping configuration generated by the state control module 300 according to a predetermined binary format, writes it byte by byte into a binary buffer containing the total number of attribute tags and each attribute configuration entry, writes the binary field to the starting position of the extended header field at an offset of 7 in the data packet, and synchronously updates the extended header length field and the message header length field, so that the attribute mapping configuration is accurately embedded in the specified position of the data packet, and the target system can locate and extract the configuration information based on the extended header length field.

[0094] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Any modifications, equivalent substitutions, and improvements made by those skilled in the art within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0095] In the description of this application, it should be noted that the terms "first", "second", and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

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

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

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

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

[0100] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the technical scope disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

[0101] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

Claims

1. A clinical data end-to-end de-identification and transfer system, characterized in that, include: The anchor point identifier generation module is used to respond to the clinical case creation event and generate a root anchor point identifier for the clinical case. The root anchor point identifier remains unchanged from the time of generation and is not repeated with any of the previously generated root anchor point identifiers. The root anchor point identifier is generated using an independent coding space that is independent of the coding space where the patient's identity information is located. The attribute tag association module is used to obtain multiple clinical attribute information of the clinical case, encapsulate each clinical attribute information into an independent attribute tag, and establish a loosely coupled association relationship between each attribute tag and the root anchor point identifier. The clinical attribute information includes patient identification information, demographic information, and diagnosis and treatment information. The state control module is used to determine the visibility status of each attribute tag in this transfer based on the target scenario of the clinical data to be transferred in the clinical case, and generate the corresponding attribute mapping configuration. The visibility status includes at least a push-back state that is available in plaintext and a pull-up state that is de-identified. The collaborative scheduling module is used to write the attribute mapping configuration into the structured fields of the data packets to be distributed when the clinical data needs to be transferred to the target system, and to distribute the data packets carrying the root anchor identifier and attribute tags in the visibility state specified by the attribute mapping configuration to the target system.

2. The end-to-end de-identification and transfer system for clinical data according to claim 1, characterized in that, The anchor point identifier generation module includes a timestamp generation unit and a random number generation unit; The timestamp generation unit is used to obtain the time of occurrence of the clinical case creation event and generate a timestamp; The random number generation unit is used to collect physical noise source signals from the hardware environment where the random number generation unit is located, and generate a fixed-length random number string after hashing the collected physical noise source signals; The root anchor identifier is formed by concatenating the timestamp, the system node identifier that runs the anchor identifier generation module, and the random number string. The generation process of the random number string does not use any patient identification information as input.

3. The end-to-end de-identification and transfer system for clinical data according to claim 1, characterized in that, The operation of the attribute tag association module to obtain the clinical attribute information and encapsulate it into attribute tags takes precedence over any de-identification processing request for the clinical case in terms of time sequence. This operation is triggered by the clinical case creation event and is not triggered by the de-identification processing request.

4. The end-to-end de-identification and transfer system for clinical data according to claim 1, characterized in that, The state control module includes an encryption processing unit and a metadata retention unit; The encryption processing unit is used to encrypt the plaintext value of an attribute tag when the visibility state of the attribute tag is determined to be the raised state. The metadata retention unit is used to retain the field name, data type, status change timestamp, and key index field of the attribute tag on the root anchor identifier after encryption.

5. The end-to-end de-identification and transfer system for clinical data according to claim 4, characterized in that, The state control module is also used to decrypt the encryption result of the attribute tag when the clinical data is switched from the current circulation scenario to a new circulation scenario. If the attribute mapping configuration corresponding to the new circulation scenario indicates that the visibility state of the attribute tag is the pushback state, the decryption operation directly obtains the key from the key index field carried by the attribute tag itself.

6. The end-to-end de-identification and transfer system for clinical data according to claim 1, characterized in that, The state control module also includes a mode parameter configuration unit; The mode parameter configuration unit is used to write a de-identification processing mode parameter field for each attribute tag in the attribute mapping configuration. The value of the de-identification processing mode parameter field includes at least a replacement processing mode and a mask processing mode. The attribute tag in the pulled-up state is presented to the outside in the data packet according to the processing mode it points to.

7. The end-to-end de-identification and transfer system for clinical data according to claim 6, characterized in that, When the de-identification processing mode parameter field of an attribute tag points to the replacement processing mode, the original plaintext value of the attribute tag is replaced with a pseudo-name value that has the same data type and the same format characteristics as the original plaintext value. When the de-identification processing mode parameter field of an attribute tag points to the masked processing mode, the characters in the original plaintext value of the attribute tag corresponding to the high-sensitivity segment are replaced with placeholder characters. The high-sensitivity segment is determined by the preset rule corresponding to the data type of the attribute tag.

8. The end-to-end de-identification and transfer system for clinical data according to claim 1, characterized in that, When the collaborative scheduling module distributes the data packet to the target system, it serializes the attribute mapping configuration and writes it into the message header of the data packet. After the target system receives the data packet, its local state control module parses the attribute mapping configuration from the message header of the data packet and determines the current visibility status of each attribute tag based on the parsed attribute mapping configuration.

9. The end-to-end de-identification and transfer system for clinical data according to claim 1, characterized in that, It also includes a status audit module, which records the visibility status change event of each attribute tag in each flow after the attribute mapping configuration takes effect. The visibility status change event includes the visibility status of the attribute tag before the flow and the visibility status after the flow.

10. The end-to-end de-identification and transfer system for clinical data according to claim 8, characterized in that, The collaborative scheduling module includes a scenario parsing unit and a configuration encapsulation unit; The scenario parsing unit is used to obtain the system type identifier of the target system and the business purpose identifier of this transfer, and combine the two into the context information of the target scenario; The configuration encapsulation unit is used to serialize the attribute mapping configuration generated by the state control module into a binary field, and write the binary field into the data packet at a specified offset position before the payload data.

Images