Medical data security processing method and device based on dynamic strategy and storage medium

Abstract

The invention discloses a medical data security processing method and device based on a dynamic strategy and a storage medium. The method comprises the following steps: receiving a resource calling instruction carrying a decentration identifier of a requester through a strategy arrangement engine; retrieving a target meta-information directory, and analyzing sensitivity grade parameters of a target information unit; determining a preset management and control reference template, and performing parametric evolution on the management and control reference template to obtain an instantiated management and control instruction set; performing attribute replacement and coding enhancement processing on the target information unit in sequence, and adding an isolation strategy mark after processing; constructing an isolation region instance of a corresponding level, and transmitting the target information unit to the isolation region instance; reading the target information unit, and associating the target information unit with a unique traceid (traceid); the traceid is loaded to a metadata domain and a frequency domain feature; and generating an output record based on the traceid, and transmitting the non-tampering abstract to a target distributed account book evidence storage system.

Description

Technical Field

[0001] This application relates to the field of big data technology, and in particular to a method, apparatus and storage medium for medical data security processing based on dynamic strategies. Background Technology

[0002] With the continuous development of medical informatization and data sharing, the scale and complexity of medical data are increasing daily. This type of data often involves patients' personal privacy, diagnosis and treatment processes, and clinical sample information related to scientific research, placing extremely stringent requirements on data security and compliance.

[0003] Currently, data protection in healthcare information systems generally relies on access control, permission allocation, and basic encrypted storage. However, with the cross-departmental and cross-institutional flow and use of healthcare data, access requests come from diverse sources and have complex purposes, posing new challenges to data security management. For example, different types of healthcare data may have varying degrees of sensitivity, requiring corresponding security measures to be implemented in their processing and use.

[0004] Therefore, in medical data management, how to achieve the rational use of data while ensuring security and compliance has become an issue of continuous concern in the industry. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a method, apparatus, and storage medium for secure medical data processing based on dynamic strategies.

[0006] The technical solution provided in this application is described below: The first aspect of this application provides a method for secure processing of medical data based on dynamic strategies, the method comprising: The strategy orchestration engine receives resource invocation instructions carrying the decentralized identifier of the requester, wherein the resource invocation instructions are used to point to a unique identifier of the target information unit; The target metadata directory is retrieved based on the unique identifier, and the sensitivity level parameters of the target information units corresponding to the target metadata directory are parsed. Based on the sensitivity level parameters, a preset control benchmark template is determined, and the control benchmark template is parameterized and evolved by combining dynamic context factors and contractual constraint rules to obtain an instantiated control instruction set. According to the control instruction set, the target information unit is sequentially subjected to attribute replacement and encoding enhancement processing, and an isolation strategy mark is attached after processing. The isolation strategy mark is used to indicate the target's operating isolation level. Based on the isolation strategy marker, an isolation zone instance of the corresponding level is constructed in a restricted computing environment supported by trusted hardware, and the processed target information unit is transmitted to the isolation zone instance; The target information unit is read through the isolation zone instance, and a unique traceability identifier, trace_id, is associated in the corresponding reading result. The trace_id is generated in the policy orchestration engine and consists of at least the requester's decentralized identifier, the target information unit identifier, a random factor, and a time series. The trace_id is loaded into the metadata field and frequency domain feature of the read result in a dual-elemental embedding manner, so that the two share the same identifier mapping; An output record is generated based on the trace_id, and an immutable digest of the output record is transmitted to the target distributed ledger evidence storage system.

[0007] Optionally, loading the trace_id into the frequency domain features of the read result in a dual-cube manner includes: The read results to be injected are standardized into a pixel matrix representation; The pixel matrix is ​​divided into several DCT blocks according to a fixed block size, wherein the block size is N×N blocks, where N is an integer that satisfies a preset computational complexity constraint, and the value of N ranges from 4 to 16. Perform a two-dimensional discrete cosine transform on the DCT block to obtain the frequency domain coefficient matrix; The embedded key is obtained by hash calculation based on the trace_id and the pre-acquired system salt value; The intermediate frequency coefficients used for embedding in the DCT block are determined based on the embedding key; The trace_id is expanded into a redundant bit string, and the redundant bit string is mapped bit by bit into several bit substrings; The redundant bit string is embedded into the intermediate frequency coefficients according to the bit substring.

[0008] Optionally, loading the trace_id into the metadata field of the read result in a dual-cubing manner includes: Construct the payload to be embedded. The payload shall include at least: trace_id, generator identifier, timestamp, version number, and checksum for integrity verification. Error correction coding is performed on the payload, and the result of the error correction coding is compressed to obtain a compressed result; The compression result is symmetrically encrypted based on the pre-shared system key to obtain the target byte string, and the target byte string is then encoded in a transmissible manner to obtain the encoded string; A steganographic field is derived from the trace_id, and the encoded string is written into the steganographic field.

[0009] Optionally, deriving a steganographic field based on the trace_id and writing the encoded string into the steganographic field includes: The encoded string is divided into m segments, where m is an integer greater than or equal to 2, and the length of each segment is a preset length; A seed is generated based on the trace_id and the pre-acquired system salt value, and the pseudo-random sequence generator is initialized with the seed; A pseudo-random sequence is generated by the pseudo-random sequence generator, and the pseudo-random sequence is used to determine the write position of the m slices; The fragments are written to the writing positions according to the pseudo-random sequence, and an imperceptible encoding perturbation is embedded in the corresponding field information.

[0010] Optionally, the step of determining a preset control benchmark template based on the sensitivity level parameter, and then parameterizing and evolving the control benchmark template in conjunction with dynamic context factors and contractual constraint rules to obtain an instantiated control instruction set includes: Based on the sensitivity level parameters, determine the control benchmark template corresponding to the sensitivity level; Collect dynamic context factors related to the resource invocation command; The contract execution module is invoked to parse the corresponding contractual constraint rules from the pre-configured digital contract. These contractual constraint rules are used to limit additional access conditions. The dynamic context factor and the contractual constraint rule are input into the management baseline template, and the parameter fields in the management baseline template are updated to obtain the management configuration; The control configuration is converted into an instantiated control instruction set.

[0011] Optionally, the step of reading the target information unit through the isolation zone instance and associating a unique traceability identifier (trace_id) with the corresponding reading result, wherein the trace_id is generated in the policy orchestration engine and consists of at least the requester's decentralized identifier, the target information unit identifier, a random factor, and a time series, including: In the isolated zone instance, the restricted access interface is invoked to perform a read operation on the target information unit, generating corresponding plaintext information; A temporary buffer is established in the isolation zone instance, and the plaintext information is written into the temporary buffer; The DID and target information unit identifier are obtained through the strategy orchestration engine, and hash values ​​are calculated respectively to obtain the first hash value and the second hash value; A random factor is generated using a secure random number generator, and a high-precision system clock is invoked to collect time series information. The first hash value, the second hash value, the random factor, and the time series are concatenated into a base string, and the base string is encoded to generate a globally unique trace identifier, trace_id.

[0012] Optionally, before reading the target information unit through the isolation zone instance and associating a unique traceability identifier `trace_id` with the corresponding reading result, wherein the `trace_id` is generated in the policy orchestration engine and consists of at least the requester's decentralized identifier, the target information unit identifier, a random factor, and a time series, the method further includes: In the isolated zone instance, a secure random number generator is invoked to generate a physical random number sequence; The first random factor is generated based on a preset seed using a pseudo-random number generator; The physical random number sequence is combined with the first random factor by an entropy fusion operation to obtain the second random factor; The strategy orchestration engine generates a trace_id based on the second random factor.

[0013] A second aspect of this application provides a medical data security processing device based on a dynamic strategy, the device comprising: The instruction receiving unit is used to receive a resource invocation instruction carrying a decentralized identifier of the requester through a policy orchestration engine. The resource invocation instruction is used to point to a unique identifier of the target information unit. The parsing unit is used to retrieve the target metadata directory based on the unique identifier and parse the sensitivity level parameters of the target information units corresponding to the target metadata directory; The instruction generation unit is used to determine a preset control benchmark template based on the sensitivity level parameters, and to perform parameterized evolution of the control benchmark template in combination with dynamic context factors and contractual constraint rules to obtain an instantiated control instruction set. The encoding conversion unit is used to perform attribute replacement and encoding enhancement processing on the target information unit in sequence according to the control instruction set, and to attach an isolation policy mark after processing. The isolation policy mark is used to indicate the target's operating isolation level. An isolation zone construction unit is used to construct an isolation zone instance of the corresponding level in a restricted computing environment supported by trusted hardware based on the isolation policy marking, and to transmit the processed target information unit to the isolation zone instance; The ID generation unit is used to read the target information unit through the isolation zone instance and associate a unique traceability identifier, trace_id, in the corresponding reading result. The trace_id is generated in the policy orchestration engine and consists of at least the requester's decentralized identifier, the target information unit identifier, a random factor, and a time series. The ID embedding unit is used to load the trace_id into the metadata field and frequency domain feature of the reading result in a dual embedding manner, so that the two share the same identifier mapping; The transmission unit is used to generate an output record based on the trace_id and transmit the immutable digest of the output record to the target distributed ledger evidence storage system.

[0014] A third aspect of this application provides a medical data security processing device based on dynamic strategies, the device comprising: Processor, memory, input / output units, and bus; The processor is connected to the memory, the input / output unit, and the bus; The memory stores a program, which the processor invokes to execute the first aspect and any one of the optional methods in the first aspect.

[0015] A fourth aspect of this application provides a computer-readable storage medium on which a program is stored, which, when executed on a computer, performs the methods of the first aspect and any one of the first aspects.

[0016] As can be seen from the above technical solutions, this application has the following beneficial effects: This invention introduces an interconnected dynamic strategy mechanism throughout the entire process of data access, processing, operation, and output, achieving organic coupling and synergistic gains across each stage. Sensitivity level parameters and dynamic context factors jointly drive the generation of control instruction sets, which, combined with isolation strategy markers, assign operational boundaries matching the data's sensitivity before it enters the trusted hardware environment, thus achieving a continuous closed loop of strategy generation, data processing, and environmental isolation. The unique traceability identifier generated and embedded during the isolation zone reading stage is not only strongly bound to the reading result through a dual embedding of metadata and frequency domains but also linked to the on-chain evidence storage mechanism. This ensures consistent technical associations between access behavior, operating environment, data output, and evidence storage logs, constructing a complete traceability chain across stages and carriers. Therefore, this invention avoids the problem of single-point reinforcement leading to overall imbalance in traditional solutions, forming a dynamically adaptive and fully traceable medical data security control system that achieves synergistic unity among security, availability, and compliance. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A schematic flowchart of an embodiment of the medical data security processing method based on dynamic strategy provided in this application; Figure 2 A schematic flowchart of an embodiment of step S103 in the dynamic strategy-based medical data security processing method provided in this application; Figure 3 A schematic flowchart of an embodiment of step S107 in the dynamic strategy-based medical data security processing method provided in this application; Figure 4 A schematic flowchart of another embodiment of step S107 in the dynamic strategy-based medical data security processing method provided in this application; Figure 5 A flowchart illustrating a specific implementation of step S274 in the dynamic strategy-based medical data security processing method provided in this application; Figure 6 A schematic flowchart of another embodiment of the medical data security processing method based on dynamic strategy provided in this application; Figure 7 A schematic diagram of an embodiment of the medical data security processing device based on dynamic strategy provided in this application; Figure 8 A schematic diagram of an embodiment of a medical data security processing device based on dynamic strategies provided in this application. Detailed Implementation

[0019] It should be understood that the method steps involved in the embodiments of the present invention can be implemented by different execution entities and are not limited to a single form. For example, the method can be completed independently by the server-side policy orchestration engine, or it can be completed collaboratively by the server and the client; it can also be partially or fully executed in an isolated operating environment based on trusted hardware (such as TEE, virtualized security modules, or containerized security zones). Furthermore, the execution entity of the method can be a medical data processing device configured with dedicated hardware modules, a general-purpose computing device running corresponding software programs, or even a distributed node collaboration. Those skilled in the art can flexibly determine the specific deployment method according to actual application needs and system architecture, and the present invention does not limit this.

[0020] To better understand the content of this application, the following is a definition of the terms used in this application: Decentralized Identity (DID): can be regarded as a symbolic credential that can represent the calling entity without centralized registration, and its form is a sequence of characters.

[0021] Target information unit: refers to a digital object that can be accessed or processed, which may be in the form of text, images, table entries or other data carriers.

[0022] Meta-information catalog: A collection of supplementary information used to describe the extended characteristics of target information units, which may include category attributes, level symbols or other abstract descriptive factors.

[0023] Sensitivity level parameter: a control symbol used to hierarchically divide target information units, which can serve as a driving factor for subsequent strategy generation.

[0024] Control baseline template: refers to a type of standardized framework that is relied upon before the strategy evolves, which may contain rules, constraints or adjustable parameter slots.

[0025] Dynamic context factors: A set of variables that change with the time and space of invocation, interaction state, or environmental conditions, used to influence the policy generation process.

[0026] Contractual constraint rules: These are constraint entries formed through pre-defined agreements that can be applied to the boundary conditions of data retrieval.

[0027] Isolation policy tag: A symbolic instruction attached to a target information unit to map to a subsequent restricted execution environment.

[0028] Isolation zone instance: refers to a restricted runtime space built with trusted support, used to perform specified operations in an isolated state.

[0029] The unique trace identifier `trace_id` is a unique mapping symbol of the call behavior during the generation process, usually composed of several identifier fragments and timing factors.

[0030] Metadata domain and frequency domain features: These refer to the symbolic appendages of a data object and the frequency-level features obtained through mathematical mapping, respectively.

[0031] Distributed ledger evidence storage system: a recording platform with decentralized and tamper-proof characteristics, used to retain corresponding call result summaries.

[0032] Please see Figure 1 This application first provides an embodiment of a medical data security processing method based on dynamic strategies, which includes: S101. Receive a resource invocation instruction carrying the decentralized identifier of the requester through the strategy orchestration engine. The resource invocation instruction is used to point to a unique identifier of the target information unit. In one implementation, the policy orchestration engine first receives a resource invocation instruction from the requester through a pre-defined interface (such as an API or message queue). This instruction carries the requester's decentralized identifier (DID) and contains a unique identifier for the target information unit. This unique identifier can be a hash-based identifier, a resource path, or an encrypted index value. This step ensures the traceability and uniqueness of the invocation request before it enters the policy execution phase.

[0033] Furthermore, in a preferred embodiment, the resource invocation instruction may be in the form of a structured message, such as JSON, Protobuf, or XML, which includes at least: The `caller_did` field stores the decentralized identity identifier of the requester. The resource_uid field: stores a unique identifier for the target information unit; The `signature` field stores the digital signature of the message body made by the caller using their private key. Optional field context: Stores context information such as timestamp, session ID, or usage description.

[0034] After receiving a resource invocation instruction, the policy orchestration engine can verify the validity of the DID in the following ways: First, based on the DID document parsing rules, it retrieves the corresponding public key from the blockchain or trusted directory service; it uses the public key to verify the signature field in the invocation instruction to confirm the identity of the caller; after the verification is successful, it binds the requester identifier to the invocation request to ensure the authenticity and non-repudiation of the caller.

[0035] Unique identifiers for target information units can be generated through different mechanisms. For example, for file-type data, a hash function (such as SHA-256) can be used to calculate its content digest as a unique identifier; for database records, a unique identifier can be generated by concatenating the table name and primary key ID and then hashing it; for streaming data, a unique identifier can be formed by combining the acquisition channel ID and timestamp, and then encoding it. These unique identifiers ensure that different types of data objects can be indexed and retrieved uniformly.

[0036] S102. Retrieve the target metadata directory based on the unique identifier, and parse the sensitivity level parameters of the target information units corresponding to the target metadata directory; The strategy orchestration engine searches the metadata directory based on the unique identifier of the target information unit. This metadata directory can be stored in a centralized database, a distributed indexing system, or an on-chain evidence table. The search results include relevant metadata for the target information unit, such as its data type (e.g., medical images, prescription entries, medical record text), data size, and generation time, and parse out its corresponding sensitivity level parameter. For example, image data might be labeled "highly sensitive," while de-identified statistical data might be labeled "low sensitive."

[0037] In one optional implementation, after receiving the unique identifier of the target information unit, the policy orchestration engine first performs a retrieval operation on the unique identifier within a preset metadata directory. The metadata directory can be implemented in various forms, such as a centralized relational database, a distributed index storage system, or a record table structure built on a blockchain network, to ensure its immutability and traceability. Through retrieval, a multi-dimensional metadata description of the target information unit can be obtained, which may include, but is not limited to, the data type (e.g., medical images, prescription entries, medical record text, or laboratory test data), data size (e.g., file size or number of records), generation or update timestamp, source system identifier, and data anonymization status. During the parsing of the metadata, the policy orchestration engine can further extract and determine the sensitivity level parameter corresponding to the information unit. The sensitivity level parameter is usually given by predefined classification criteria of the system, such as low sensitivity, medium sensitivity, or high sensitivity levels, to reflect the differences in data security management and access control requirements. For example, unanonymized raw medical images may be judged as highly sensitive, while de-identified statistical indicator data may be judged as low sensitive. In this way, the policy orchestration engine can execute differentiated control policies based on explicit sensitivity levels in subsequent steps.

[0038] S103. Determine a preset control benchmark template based on the sensitivity level parameters, and perform parameterized evolution of the control benchmark template in combination with dynamic context factors and contractual constraint rules to obtain an instantiated control instruction set. Based on the sensitivity level parameters obtained from the parsing, the system determines a preset control baseline template. This template may contain default boundaries for access permissions, operational scope, or encryption policy placeholders. Building upon this, the system combines real-time context factors (such as request time, visitor location, and terminal trust level) and constraints defined in the digital contract (such as permission for research use only, prohibition of secondary distribution) to parameterize the baseline template, thereby generating an instantiated control instruction set. For example, if the call originates from an internal research node during working hours, the instruction set may relax access permissions for some fields; conversely, if the call originates from an external terminal, the instruction set automatically loads stricter de-identification rules.

[0039] See Figure 2 In an optional embodiment, step S103 can be implemented as follows: S1031. Based on the sensitivity level parameters, determine the control benchmark template corresponding to the sensitivity level; In step S1031, the policy orchestration engine first retrieves and determines the corresponding control baseline template from a predefined policy library based on the sensitivity level parameter of the target information unit. The control baseline template can be a set of rules or a parameter framework, containing basic constraints on access authentication, data processing intensity, isolation environment requirements, etc. For example, for highly sensitive target information units, the corresponding control baseline template may have pre-set rules such as "mandatory encrypted access," "trusted isolation execution," and "multimodal watermarking," while for low-sensitivity data, only a lighter access control policy may be required.

[0040] S1032. Collect dynamic context factors related to the resource call command; In this step, the policy orchestration engine collects dynamic context factors related to the resource invocation command. These context factors may include access time (e.g., working or non-working hours), access location (e.g., whether within the hospital's network environment), invocation terminal type (e.g., mobile or fixed terminal), and invocation purpose (e.g., research statistics or clinical diagnosis). These context factors are dynamically introduced into the policy generation process through real-time collection and parsing, enabling contextual adjustments to the control rules.

[0041] S1033. Call the contract execution module to parse the corresponding contractual constraint rules from the pre-configured digital contract. The contractual constraint rules are used to limit additional access conditions. In step S1033, the strategy orchestration engine calls the contract execution module to parse contractual constraint rules related to the current call scenario from pre-configured digital contracts. The digital contracts can be pre-stored in a trusted ledger or rule database, and their content includes additional access restrictions, such as "the maximum number of calls by the same DID within a certain time window," "multi-factor authentication is required for cross-regional calls," or "research calls require approval from an ethics committee." Through the contract execution module, the system can automatically identify and extract contractual constraint entries matching the current request, thereby introducing mandatory constraints into strategy generation.

[0042] S1034. Input the dynamic context factor and the contractual constraint rule into the management baseline template, and update the parameter fields in the management baseline template to obtain the management configuration; In step S1034, the policy orchestration engine inputs the dynamic context factor and the contractual constraint rules into the control baseline template and updates the parameter fields in the template. For example, in the "Encryption Strength" parameter field of the template, the encryption algorithm type can be dynamically adjusted according to whether the access location is an off-site network; in the "Access Frequency Limit" parameter field, it can be overwritten and updated according to the call limit value specified by the digital contract; and in the "Audit Policy" parameter field, the granularity of log recording can be dynamically increased according to the sensitivity of the context factor. Through the above parameterization evolution process, the control baseline template is customized to a control configuration adapted to the current call request.

[0043] S1035. Convert the control configuration into an instantiated control instruction set.

[0044] The policy orchestration engine transforms the control configuration into an executable, instantiated set of control instructions. This set of instructions can be stored as a rule tree, bytecode, or script, and is parsed and executed line by line during subsequent data processing and isolation execution.

[0045] S104. According to the control instruction set, the target information unit is sequentially subjected to attribute replacement and encoding enhancement processing, and an isolation strategy mark is attached after processing. The isolation strategy mark is used to indicate the target's operating isolation level. After obtaining the instantiated control instruction set, the system preprocesses the target information unit. Preprocessing includes, but is not limited to: replacing certain sensitive fields (e.g., replacing ID numbers with random strings), semantically perturbing text, or encoding and encrypting images. Subsequently, an isolation policy marker is appended to the processed information unit. This marker symbolically indicates the isolation level at which the target is operating. For example, multi-level enumeration values ​​(Level-1, Level-2, Level-3) can be used, corresponding to low, medium, and high security isolation levels, respectively.

[0046] Specifically, in one optional implementation, the system first performs substitution processing on sensitive attributes present in the target information unit according to the rules set in the instruction set. This substitution processing can take the form of direct replacement, such as replacing highly sensitive fields like ID card numbers and contact information with random strings of consistent length or de-identified identifiers to maintain data structure integrity. Alternatively, it can employ semantic preservation methods, such as replacing patient names appearing in medical record text with similar words or anonymized symbols, thereby reducing the risk of sensitive data leakage while improving the usability of data analysis. For image or sequence data, the substitution processing can manifest as masking image pixel areas or perturbing and rearranging key segments of the sequence to weaken potentially sensitive features.

[0047] Furthermore, the system performs encoding enhancement processing to improve data security during transmission and storage. This encoding enhancement processing can include multi-layered operations, such as introducing multiple character encodings and overlaying lightweight encryption algorithms on text data, performing block-based encrypted compression on image data, or applying redundant checksums to structured tabular data to enhance integrity protection. Through these methods, the target information unit not only possesses basic de-identification characteristics but also the ability to resist illegal parsing at intermediate stages.

[0048] The system attaches an isolation policy tag to the processed information unit. This tag indicates the isolation level at which the target information unit should operate in a restricted computing environment. The isolation policy tag can be symbolic or enumerated, for example, set as different identifiers such as Level-1, Level-2, and Level-3 to correspond to low, medium, and high security isolation levels. In some specific implementations, the isolation policy tag can also be embedded in the metadata field or control header of the information unit, and an immutable verification mechanism ensures it remains attached throughout the data's lifecycle. In this way, when scheduling or constructing isolation zone instances, the system can quickly determine the required security environment level based on this tag, thereby achieving seamless integration between the control policy and the execution environment.

[0049] S105. Based on the isolation strategy marker, construct an isolation zone instance of the corresponding level in a restricted computing environment supported by trusted hardware, and transmit the processed target information unit to the isolation zone instance. Based on isolation policy tags, the policy orchestration engine constructs corresponding isolation zone instances within a restricted computing environment supported by trusted hardware. This computing environment can be a secure runtime space based on a Trusted Execution Environment (TEE), a secure virtual machine container, or other hardware isolation technologies. After the isolation zone instance is constructed, the system transmits the pre-processed target information unit to the instance's internal storage area. At this point, the information unit exists in encrypted form outside the isolation zone and can only be decoded and processed in plaintext form within the instance, thus preventing unauthorized access.

[0050] Furthermore, in an optional embodiment, the policy orchestration engine needs to parse the isolation policy tag attached to the target information unit and, based on the isolation level indicated by the tag, construct the corresponding isolation zone instance in a restricted computing environment supported by trusted hardware. The restricted computing environment can be implemented by various secure hardware mechanisms, such as a processor-embedded Trusted Execution Environment (TEE), a secure container using virtualization technology, or a hardware isolation module based on an independent security chip. During the construction process, the system calls the underlying hardware's security extension instructions to allocate independent memory space, execution context, and access control table to the isolation zone instance, and establishes the initial security state of the instance through hardware root trust.

[0051] Once the isolation zone instance is created, the system transmits the processed target information unit to the instance's internal storage area. During transmission, the target information unit remains encrypted and encapsulated, and the transmission channel is protected by session keys or secure transmission protocols (such as TLS or hardware encryption buses) to prevent data theft or tampering during transmission. After the target information unit enters the isolation zone instance, the instance's internal decryption module uses a trusted key to decapsulate the data, allowing it to be accessed and processed in plaintext within a limited memory space. During this process, the key material is not leaked outside the instance, and ordinary execution environments outside the instance cannot directly access the data within the isolation zone.

[0052] Through the above methods, the processed target information unit can only be parsed and used within the corresponding isolation zone instance. Even if external applications or unauthorized processes obtain an encrypted copy of the data, they cannot decode it or perform illegal operations, thus effectively preventing unauthorized access and information leakage. Furthermore, different levels of isolation policy labels can correspond to isolation zones of different security strengths. For example, a Level-1 isolation zone allows limited shared interfaces, while a Level-3 isolation zone completely blocks external interactions, retaining only controlled access channels to meet the multi-layered security protection needs of information units with varying levels of sensitivity.

[0053] S106. Read the target information unit through the isolation zone instance, and associate a unique traceability identifier (trace_id) with the corresponding reading result. The trace_id is generated in the policy orchestration engine and consists of at least the requester's decentralized identifier, the target information unit identifier, a random factor, and a time series. Within the isolation zone, the system invokes the restricted access interface to perform a read operation on the target information unit and generates a corresponding read result. Simultaneously, the policy orchestration engine generates a unique traceability identifier, `trace_id`. This `trace_id` consists of at least the requester's DID, the target information unit identifier, a random factor, and a time series. For example, `trace_id` can be represented as `T_xxxDIDhash_xxxDataHash_20240910123045_Rand256`. This identifier is embedded in the read result to ensure the traceability of subsequent data flow processes.

[0054] Specifically, one implementation of this step includes: calling the restricted access interface in the isolation zone instance to perform a read operation on the target information unit and generating corresponding plaintext information; establishing a temporary buffer in the isolation zone instance and writing the plaintext information into the temporary buffer; obtaining the DID and the target information unit identifier through the policy orchestration engine, and calculating hash values ​​respectively to obtain a first hash value and a second hash value; generating a random factor through a secure random number generator and calling a high-precision system clock to collect time series information; concatenating the first hash value, the second hash value, the random factor, and the time series into a base string, and encoding the base string to generate a globally unique trace identifier trace_id.

[0055] In the above implementation, a restricted access interface is first invoked within the isolation zone instance to perform a controlled read operation on the target information unit, thus preventing unauthorized external processes from directly accessing the original data. After the read operation is completed, the system generates the corresponding plaintext information and establishes a temporary buffer within the isolation zone to temporarily store this plaintext information. During this process, the temporary buffer only exists within the lifetime of the isolation zone and is automatically cleaned up, being destroyed immediately after the task ends to prevent plaintext residue.

[0056] The strategy orchestration engine obtains the decentralized identity (DID) provided by the requester and the unique identifier of the target information unit, and then calls a hash function (such as SHA-256 or a higher-security hash algorithm) to calculate the first hash value and the second hash value, respectively. The first hash value and the second hash value serve as the unique identifiers of the requester and the target information unit, respectively.

[0057] During this process, a secure random number generator is invoked within the isolated instance to generate a high-entropy random factor. This high-entropy random factor can be generated based on a hardware entropy source or a certified pseudo-random number generator, thus making it unpredictable. The system also collects time-series information through a high-precision system clock, with nanosecond-level or higher precision, to distinguish access requests triggered at different times.

[0058] The system concatenates the first hash value, the second hash value, the random factor, and the time series sequentially into a basic string, and then calls the encoding module for formatting, such as using Base64 encoding or URL-secure encoding, so that this basic string can be used across different storage and transmission channels. This generates a globally unique traceability identifier, `trace_id`, which is then bound to the read result for consistent identification in subsequent watermark injection and evidence storage. Through this method, `trace_id` simultaneously possesses uniqueness, unpredictability, and cross-scenario verifiability, thereby significantly improving the security and robustness of the traceability system.

[0059] S107. Load the trace_id into the metadata field and frequency domain feature of the reading result in a dual-embedded manner, so that the two share the same identifier mapping; To further enhance the robustness of traceability identification, the system loads `trace_id` into the read results using a dual-embedding approach. On one hand, `trace_id` is written as a hidden field into the metadata field of the read results, for example, by inserting a `trace_id` field into the JSON output. On the other hand, `trace_id` is converted into a specific symbol string, which is then embedded into the frequency domain coefficients of the image or document via Discrete Cosine Transform (DCT), thus forming an invisible watermark. In this way, even if the metadata is tampered with, the frequency domain watermark can still retain the corresponding information, achieving dual verification.

[0060] In step S107, the system needs to bind the generated trace_id with the reading result to achieve subsequent traceability and tamper detection. Since different types of data output have their own forms of expression and technical characteristics, there are multiple implementation paths for loading trace_id. Therefore, this application provides two representative implementation schemes, corresponding to embedding trace_id in the metadata domain of the reading result and embedding trace_id in the frequency domain features of the reading result, respectively. The former method is more suitable for processing structured or semi-structured data scenarios, and can achieve identification records with lower computational cost; the latter method is more suitable for processing image or document data scenarios, and can achieve deep steganography without affecting perceptual quality. Those skilled in the art can choose one method according to specific application requirements, or combine both methods for dual embedding, to enhance the robustness and anti-circumvention capabilities of the identification.

[0061] The following is a detailed description of the implementation examples for these two methods: Example 1: This embodiment targets image or document reading results, employing a block-based frequency domain embedding scheme to embed the previously generated unique trace identifier (trace_id) into the frequency domain coefficients of the output file, achieving a concealed and robust identifier carrying. This implementation requires first normalizing the object to be embedded into a pixel matrix and dividing it into N×N blocks. Then, redundant bit strings of the error-corrected and redundancy-expanded trace_id are embedded into the mid-frequency coefficients of each block according to pseudo-random and keyed rules. The embedding strength can be adaptively set according to the trade-off between perceptual masking and robustness. After embedding, the temporal output can be recovered through inverse transformation and post-processing while maintaining visual imperceptibility. The specific steps are explained below.

[0062] See Figure 3 The implementation methods include: S171. Standardize the reading results to be injected into a pixel matrix representation; The read results to be injected (bitmap pages of images, scans, or documents) are converted into a unified temporal representation. This step first requires color space conversion of the color image as needed (e.g., from RGB to YCbCr), and prioritizing the luma channel (Y) or grayscale image to balance perceptual impact and embedding capacity. Subsequently, the image is normalized or resolution preserved (if necessary, images exceeding the maximum size are scaled in blocks according to a predetermined strategy), and invalid pixel areas (such as margins) are masked to avoid wasting embedding capacity in non-information areas. After completing these steps, the image is represented as a pixel matrix, which serves as input for subsequent block segmentation and DCT operations.

[0063] S172. Divide the pixel matrix into several DCT blocks according to a fixed block size, wherein the block size is N×N blocks, where N is an integer that satisfies the preset computational complexity constraint, and the value of N ranges from 4 to 16. The pixel matrix is ​​divided into several non-overlapping DCT blocks of a preset block size N×N, where N is an integer that satisfies the system's computational complexity constraints, with a value range limited to 4 to 16 (preferably N=8 for compatibility with common JPEG / image processing standards). Considerations for choosing N: a smaller N improves robustness to local tampering and embedding granularity, while a larger N increases the usable frequency domain capacity of each block and may improve frequency domain stability; in practical engineering, an appropriate N can be selected within this range based on the output type, desired robustness, and processing performance. To reduce artificial traces at block boundaries, overlapping areas can be reserved after block division or deblocking filtering can be used after the inverse transform.

[0064] S173. Perform a two-dimensional discrete cosine transform on the DCT block to obtain the frequency domain coefficient matrix; Perform a two-dimensional discrete cosine transform (2DDCT) on each N×N block to obtain the corresponding frequency domain coefficient matrix. The full precision of the transform coefficients should be preserved, or necessary quantization parameters should be recorded before quantization (if the output will subsequently require quantization). To ensure embedding invisibility, DC components and extremely high-frequency terms are pre-excluded as embedding candidates. The mid-frequency coefficients are given priority consideration, as this range offers good resistance to common compression and mild noise while minimizing significant visual distortion.

[0065] S174. Obtain the embedding key by performing a hash calculation based on the trace_id and the pre-acquired system salt value; Based on the generated trace_id and the system's pre-set salt value or key, an embedded key (key_emb) is derived using a hash or message authentication function (e.g., HMAC-SHA256). This embedded key serves as both the seed for the pseudo-random sequence generator (PRNG) and for the keyed derivation of subsequent coefficient selection and modulation parameters. By deriving the key from the trace_id, only the party holding the same salt value / key can accurately reproduce the embedded location and parameters, thereby improving concealment and security.

[0066] S175. Determine the intermediate frequency coefficients used for embedding in the DCT block according to the embedding key; A high-quality pseudo-random number generator (PRNG) initialized with the embedding key is used to select the set of intermediate frequency coefficients for embedding within each DCT block or across a global map spanning several blocks. The selection rules need to avoid DC (direct current) and high-frequency noise bands. This can be achieved using a predefined "Zig-zag" index mapping with a defined index range (e.g., index 2 to k), or by employing a perceptual masking model combined with adaptive selection based on block energy. To enhance resistance to pruning and local disruption, selection can be distributed across multiple blocks with spatial redundancy across the entire map.

[0067] S176. Expand the trace_id into a redundant bit string, and map the redundant bit string bit by bit into several bit substrings; In this step, after converting trace_id into a binary string, error correction encoding (such as using BCH or Reed-Solomon encoding) is required to generate redundant bit strings, thereby improving the recovery rate under compression, pruning, or noise. Subsequently, the error correction results can be interleaved to disperse the impact of burst errors, and the redundant bit strings can be divided into several bit substrings according to the required concealment capacity for block-by-block mapping.

[0068] S177. Embed the redundant bit string into the intermediate frequency coefficient according to the bit substring.

[0069] In this step, the aforementioned bit substring is mapped bit by bit to the selected intermediate frequency coefficients. The coefficients can be adjusted to represent the corresponding bits using methods such as Quantization Indexed Modulation (QIM), Additive Amplitude Modulation, or Minimal Modification (e.g., an enhanced version of LSB-replacement). To balance invisibility and robustness, the embedding intensity can be adaptively allocated according to perceptual masking (e.g., setting an amplitude ratio α relative to the coefficient amplitude, preferably in the range of 0.01–0.1). Simultaneously, multiple repetitions and distributed embedding are implemented at each bit to achieve spatial redundancy. After modulating all target coefficients, Inverse DCT (IDCT) can be performed on each block, and deblocking and color gamut / luminance restoration can be applied to the entire image to generate the final reading result of the embedded frequency domain watermark.

[0070] During the embedding site recovery phase, the receiver first uses the same key derivation mechanism and system salt value as the embedding phase to reconstruct the embedding key. This embedding key is then used as the seed for a pseudo-random number generator (PRNG) to reconstruct the pseudo-random coefficient selection sequence used during embedding, thereby locating the previously selected intermediate frequency coefficients in the DCT block of the file to be examined. Subsequently, the quantization index or amplitude difference of the located coefficients is read, and the original bit substring sequence is reconstructed according to the reverse mapping rules used during embedding. The reconstructed bitstream is first de-interleaved and then error-correcting decoded (e.g., BCH or Reed-Solomon decoding) to recover the original trace_id string or its encoded form. The recovered trace_id can be further cross-validated with the metadata watermark in the structured output or with the digest of the on-chain / local evidence record. If the cross-validation passes, the validity and consistency of the extracted result with the source are confirmed; if the cross-validation fails, a redundant verification or manual forensics process is triggered.

[0071] Example 2: In another alternative implementation, to securely embed the trace_id and its associated information into the metadata field of the read result, this application proposes an embedding method based on structured payload and steganographic fields. This method constructs the payload from the trace_id and several auxiliary information, and through encoding, encryption, and steganography, organically extends the metadata field of the read result, ensuring the integrity and concealment of the trace identifier, and enabling efficient recovery and verification in subsequent parsing stages.

[0072] See Figure 4 The implementation methods include: S271. Construct the payload to be embedded, wherein the payload includes at least: trace_id, generator identifier, timestamp, version number, and checksum for integrity verification; In step S271, the payload to be embedded is first constructed. The payload includes at least the core trace identifier `trace_id`, as well as an additional generator identifier, generation timestamp, version number, and checksum required for integrity verification. The `trace_id` establishes a one-to-one correspondence with the specific call request; the generator identifier distinguishes different data processing nodes or system instances; the timestamp characterizes the embedding time dimension; the version number ensures compatibility with future format upgrades; and the checksum enables rapid verification of the payload's validity during the extraction phase.

[0073] S272. Perform error correction coding on the payload and compress the result of the error correction coding to obtain a compressed result; In this step, the constructed payload undergoes redundancy and fault tolerance processing. Specifically, error-correcting coding (such as BCH, Reed-Solomon, or LDPC coding) can be used to redundantly expand the payload content, making it resistant to transmission errors or storage disturbances. Subsequently, compression operations are performed on the encoded result, such as entropy coding (Huffman or arithmetic coding) or general compression algorithms (such as DEFLATE), thereby reducing the length of the final embedded data and improving embedding efficiency and space utilization.

[0074] S273. The compression result is symmetrically encrypted based on the pre-shared system key to obtain the target byte string, and the target byte string is transmissibly encoded to obtain the encoded string; The compressed data is further encrypted and encoded. Specifically, based on a pre-shared system key, a symmetric encryption algorithm (such as AES-CTR or ChaCha20) is used to encrypt the compressed result to obtain the target byte string. The encrypted data is then encoded for transmission, such as Base64 or Base85, so that it can be securely embedded into the metadata structure in text form, thus avoiding compatibility issues due to differences in character sets or transmission protocols.

[0075] S274. Derive a steganographic field based on the trace_id and write the encoded string into the steganographic field.

[0076] In step S274, a corresponding steganographic field is derived based on the trace_id. This field name can be obtained by performing a hash operation on the trace_id, extracting a portion of its bits, or mapping it to a system salt value, ensuring that different trace_ids correspond to different field identifiers to avoid embedding conflicts. The encoded string obtained in the preceding steps is written into this steganographic field and published as part of the metadata field of the read result. Thus, the trace_id and its related information are embedded into the read result in a concealed manner, ensuring both information security and traceability while maintaining compatibility and transparency of external data at the structural level.

[0077] See Figure 5 Specifically, the following provides an implementation method for step S274, which includes: S2741. Divide the encoded string into m segments, where m is an integer greater than or equal to 2, and the length of each segment is a preset length; S2742. Generate a seed based on the trace_id and the pre-acquired system salt value, and initialize the pseudo-random sequence generator with the seed; S2743. A pseudo-random sequence is generated by the pseudo-random sequence generator, and the pseudo-random sequence is used to determine the write position of the m fragments; S2744. The fragments are written to the writing positions according to the pseudo-random sequence, and an imperceptible encoding perturbation is embedded in the corresponding field information.

[0078] In this embodiment, the encoded string needs to be segmented first, dividing it into m sub-segments, where m is an integer greater than or equal to 2. The length of each segment can be fixed according to a preset rule or adaptively adjusted according to the overall length to ensure uniformity and controllability after segmentation. The system uses trace_id and a pre-acquired system salt value to generate a random seed, and initializes a pseudo-random sequence generator with this random seed. Based on the pseudo-random sequence generated by the pseudo-random sequence generator, the writing position of each sub-segment in the structured output can be determined. This writing position can cover information fields such as non-significant fields, hidden rows, or reserved columns, thereby avoiding significant interference with the main data information. After completing the position mapping, the system writes each segment to the corresponding target position in a distributed manner, and superimposes imperceptible encoding perturbations into the field names or field values. For example, it uses special control symbols or character set characteristics that are difficult to render directly to achieve implicit payload carrying, thereby effectively increasing the difficulty of external detection and removal. In this way, the encoded string is carried in the reading result in a combination of distributed and steganographic methods, which significantly improves the adversarial and robust properties, while further enhancing the concealment while ensuring the complete transmission of information.

[0079] In an alternative implementation, the "imperceptible coding perturbation" described in this application refers to a type of symbolic modification introduced at the data representation level that does not affect the main semantics or structured parsing results but can carry additional implicit information. For example, code points belonging to a special control character set can be inserted into field names or field values, or invisible whitespace-like symbols can be embedded in text sequences, thereby remaining imperceptible during visual or conventional parsing processes; alternatively, implicit payload mapping can be achieved using bidirectional byte order markers, unassigned or rarely used Unicode range characters. Those skilled in the art will understand that the above perturbations will not change the original data semantics or display effect in the reading results, but can serve as a steganographic channel to carry fragmented information, thereby enhancing the concealment and robustness of the overall embedding mechanism.

[0080] To fully describe the dual extraction and verification process of embedding the payload into the metadata domain in Example 2, the following supplementary explanation is provided for the extraction stage: During the extraction phase, the steganographic field needs to be determined based on the known trace_id or through candidate field scanning. If the trace_id has been obtained from other channels (such as frequency domain watermark extraction or on-chain records), the system can re-encode the steganographic field derivation algorithm based on the trace_id and the system salt / mapping rules to directly locate the corresponding steganographic field; if the trace_id is not available immediately, the system can perform candidate field scanning on the structured output metadata field, and select several suspected steganographic fields as candidates based on field name patterns, lengths, and character set characteristics.

[0081] After locating the steganographic field, the system reads the encoded string within the field and performs the inverse operation of the transmissible encoding (e.g., Base64 or Base85 decoding) to obtain the encrypted target byte string. In implementations handling fragmented writes or sharded storage, the system first reassembles the shards according to a derived pseudo-random sequence or on-chain records, and then concatenates them into a complete byte string in the original shard order. If some shards are missing, redundancy or error correction information can be used for recovery. Symmetric decryption is then performed using the pre-shared key to obtain the compressed result. Decompression and error correction decoding are then performed on the compressed result to recover the payload. The payload should at least contain trace_id, generator identifier, timestamp, version number, and checksum. Finally, the system performs integrity verification on the payload checksum and compares the trace_id with on-chain evidence or metadata records. If the verification matches, the extraction is confirmed as valid; otherwise, an anomaly alarm is triggered.

[0082] S108. Generate an output record based on the trace_id, and transmit the tamper-proof digest of the output record to the target distributed ledger evidence storage system.

[0083] After the read result is generated, the system creates a corresponding output record based on the trace_id. This record includes the data call timestamp, the caller's DID, the target information unit identifier, and watermark mapping information. Subsequently, the system performs a digest operation on the output record (e.g., generating a hash value using SHA-256) and writes this immutable digest to the target distributed ledger notarization system. In this way, even if external storage is tampered with, the authenticity and integrity of the data read result can be verified through on-chain digest comparison.

[0084] To further enhance the randomness and unpredictability of traceability identifiers, the method introduces a multi-source randomness fusion process before generating the trace_id. Specifically, this embodiment obtains a physical random number sequence by calling a secure random number generator within the isolation zone instance, and combines it with a first random factor output by a pseudo-random number generator driven by a preset seed, performing an entropy fusion operation to generate a second random factor. This second random factor is used as a core perturbation factor input to the policy orchestration engine, which then generates a globally unique trace_id based on it. This ensures that the traceability identifier is not only associated with the requester identifier, target information unit identifier, and time series, but also possesses higher unpredictability and collision avoidance capabilities. The following describes an embodiment of this dynamic policy-based medical data security processing method; see reference [link to documentation]. Figure 6 This embodiment includes: S201. Receive a resource invocation instruction carrying the decentralized identifier of the requester through the strategy orchestration engine. The resource invocation instruction is used to point to a unique identifier of the target information unit. S202. Retrieve the target metadata directory based on the unique identifier, and parse the sensitivity level parameters of the target information units corresponding to the target metadata directory; S203. Determine a preset control benchmark template based on the sensitivity level parameters, and perform parameterized evolution of the control benchmark template in combination with dynamic context factors and contractual constraint rules to obtain an instantiated control instruction set. S204. According to the control instruction set, the target information unit is sequentially subjected to attribute replacement and encoding enhancement processing, and an isolation strategy mark is attached after processing. The isolation strategy mark is used to indicate the target's operating isolation level. S205. Based on the isolation strategy marker, construct an isolation zone instance of the corresponding level in a restricted computing environment supported by trusted hardware, and transmit the processed target information unit to the isolation zone instance. S206. In the isolated zone instance, call the secure random number generator to generate a physical random number sequence; S207. Generate a first random factor based on a preset seed using a pseudo-random number generator; S208. Perform an entropy fusion operation on the physical random number sequence and the first random factor to obtain the second random factor; S209. Generate trace_id based on the second random factor using the strategy orchestration engine; In this embodiment, before reading the target information unit through the isolation zone instance and associating it with the unique traceability identifier `trace_id` in the corresponding reading result, a process of generating a random factor to enhance randomness is further included. Specifically, firstly, a built-in secure random number generator is invoked within the isolation zone instance to obtain a physical random number sequence. This physical random number sequence originates from hardware entropy sources, such as physical phenomena based on thermal noise, clock jitter, or circuit bias. Its reading result is difficult to predict through algorithms, thus providing a high-entropy basis for subsequent identifier generation. Subsequently, the system generates a first random factor under the drive of a preset seed using a pseudo-random number generator. The pseudo-random number generator can be a linear congruent generator, a Mersenne Twister, or a hardware-accelerated pseudo-random module, and its reading result has controllable repeatability and high statistical randomness.

[0085] Based on this, the system inputs the physical random number sequence and the first random factor into the entropy fusion module, and performs an entropy fusion operation to generate a second random factor. The entropy fusion operation can be implemented using bitwise XOR, linear mixing, or a combination of hash functions, so that the fused random factor possesses both the unpredictability of physical random numbers and the uniform distribution characteristics of pseudo-random numbers, thus achieving a balance between randomness and robustness. The strategy orchestration engine receives this second random factor and uses it, along with the requester's decentralized identifier (DID), target information unit identifier, and time series information, as input, generating a globally unique trace_id through preset encoding or hashing rules. Through this process, the generated trace_id not only possesses a deterministic binding relationship, but also, due to the introduction of a multi-source entropy fusion mechanism, significantly improves its unpredictability and collision resistance, ensuring a high level of uniqueness and security even in large-scale multi-user concurrent scenarios.

[0086] S210. Read the target information unit through the isolation zone instance, and associate a unique traceability identifier (trace_id) with the corresponding reading result. The trace_id is generated in the policy orchestration engine and consists of at least the requester's decentralized identifier, the target information unit identifier, a random factor, and a time series. S211. Load the trace_id into the metadata field and frequency domain feature of the reading result in a dual-embedded manner, so that the two share the same identifier mapping; S212. Generate an output record based on the trace_id, and transmit the immutable digest of the output record to the target distributed ledger evidence storage system.

[0087] It should be understood that the foregoing method embodiments are merely several exemplary processes for implementing the technical solution of this application, used to illustrate the core processing logic and key steps. After reading the above content, those skilled in the art can complete the corresponding functions based on the same design concept through a combination of software and hardware. Therefore, in order to further illustrate the technical solution of this application, the device structure that can be used to execute the above method will be described below in conjunction with the device embodiment. It should be noted that the device embodiment corresponds to the foregoing method embodiment, and its functional modules can correspond one-to-one with the method steps, but it is not limited to adopting the exact same division method. Different modules can also be merged, split, or implemented in an equivalent form according to specific implementation needs.

[0088] See Figure 7 This application provides a medical data security processing device based on dynamic strategies, the device comprising: Instruction receiving unit 701 is used to receive a resource invocation instruction carrying the decentralized identifier of the requester through the strategy orchestration engine. The resource invocation instruction is used to point to a unique identifier of the target information unit. The parsing unit 702 is used to retrieve the target metadata directory based on the unique identifier and parse the sensitivity level parameters of the target information units corresponding to the target metadata directory; The instruction generation unit 703 is used to determine a preset control benchmark template based on the sensitivity level parameters, and to perform parameterized evolution of the control benchmark template in combination with dynamic context factors and contractual constraint rules to obtain an instantiated control instruction set. The encoding conversion unit 704 is used to perform attribute replacement and encoding enhancement processing on the target information unit in sequence according to the control instruction set, and to attach an isolation strategy mark after processing. The isolation strategy mark is used to indicate the target's operating isolation level. The isolation zone construction unit 705 is used to construct an isolation zone instance of the corresponding level in a restricted computing environment supported by trusted hardware based on the isolation policy mark, and to transmit the processed target information unit to the isolation zone instance; ID generation unit 706 is used to read the target information unit through the isolation zone instance and associate a unique traceability identifier trace_id in the corresponding reading result. The trace_id is generated in the policy orchestration engine and consists of at least the requester's decentralized identifier, the target information unit identifier, a random factor, and a time series. ID embedding unit 707 is used to load the trace_id into the metadata field and frequency domain feature of the reading result in a dual embedding manner, so that the two share the same identifier mapping; The transmission unit 708 is used to generate an output record based on the trace_id and transmit the immutable digest of the output record to the target distributed ledger evidence storage system.

[0089] Optionally, the ID fitting unit 707 is specifically used for: The read results to be injected are standardized into a pixel matrix representation; The pixel matrix is ​​divided into several DCT blocks according to a fixed block size, wherein the block size is N×N blocks, where N is an integer that satisfies a preset computational complexity constraint, and the value of N ranges from 4 to 16. Perform a two-dimensional discrete cosine transform on the DCT block to obtain the frequency domain coefficient matrix; The embedded key is obtained by hash calculation based on the trace_id and the pre-acquired system salt value; The intermediate frequency coefficients used for embedding in the DCT block are determined based on the embedding key; The trace_id is expanded into a redundant bit string, and the redundant bit string is mapped bit by bit into several bit substrings; The redundant bit string is embedded into the intermediate frequency coefficients according to the bit substring.

[0090] Optionally, the ID fitting unit 707 is specifically used for: Construct the payload to be embedded. The payload includes at least: trace_id, generator identifier, timestamp, version number, and checksum for integrity verification. Error correction coding is performed on the payload, and the result of the error correction coding is compressed to obtain a compressed result; The compression result is symmetrically encrypted based on the pre-shared system key to obtain the target byte string, and the target byte string is then encoded in a transmissible manner to obtain the encoded string; A steganographic field is derived from the trace_id, and the encoded string is written into the steganographic field.

[0091] Optionally, the ID fitting unit 707 is specifically used for: The encoded string is divided into m segments, where m is an integer greater than or equal to 2, and the length of each segment is a preset length; A seed is generated based on the trace_id and the pre-acquired system salt value, and the pseudo-random sequence generator is initialized with the seed; A pseudo-random sequence is generated by the pseudo-random sequence generator, and the pseudo-random sequence is used to determine the write position of the m slices; The fragments are written to the writing positions according to the pseudo-random sequence, and an imperceptible encoding perturbation is embedded in the corresponding field information.

[0092] Optionally, the instruction generation unit 703 is specifically used for: Based on the sensitivity level parameters, determine the control benchmark template corresponding to the sensitivity level; Collect dynamic context factors related to the resource invocation command; The contract execution module is invoked to parse the corresponding contractual constraint rules from the pre-configured digital contract. These contractual constraint rules are used to limit additional access conditions. The dynamic context factor and the contractual constraint rule are input into the management baseline template, and the parameter fields in the management baseline template are updated to obtain the management configuration; The control configuration is converted into an instantiated control instruction set.

[0093] Optionally, the ID generation unit 706 is specifically used for: In the isolated zone instance, the restricted access interface is invoked to perform a read operation on the target information unit, generating corresponding plaintext information; A temporary buffer is established in the isolation zone instance, and the plaintext information is written into the temporary buffer; The DID and target information unit identifier are obtained through the strategy orchestration engine, and hash values ​​are calculated respectively to obtain a first hash value and a second hash value; A random factor is generated using a secure random number generator, and a high-precision system clock is invoked to collect time series information. The first hash value, the second hash value, the random factor, and the time series are concatenated into a base string, and the base string is encoded to generate a globally unique trace identifier, trace_id.

[0094] Optionally, it also includes an entropy fusion unit 709, specifically used for: In the isolated zone instance, a secure random number generator is invoked to generate a physical random number sequence; The first random factor is generated based on a preset seed using a pseudo-random number generator; The physical random number sequence is combined with the first random factor by an entropy fusion operation to obtain the second random factor; The strategy orchestration engine generates a trace_id based on the second random factor.

[0095] Please see Figure 8 This application also provides a medical data security processing device based on dynamic strategies, comprising: Processor 801, memory 802, input / output unit 803, bus 804; The processor 801 is connected to the memory 802, the input / output unit 803, and the bus 804; The memory 802 stores a program, and the processor 801 calls the program to execute any of the methods described above.

[0096] This application also relates to a computer-readable storage medium on which a program is stored, which, when run on a computer, causes the computer to perform any of the methods described above.

[0097] Those skilled in the art will clearly 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.

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

[0099] 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.

[0100] Furthermore, 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0101] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for secure processing of medical data based on dynamic strategies, characterized in that, The method includes: The strategy orchestration engine receives resource invocation instructions carrying the decentralized identifier of the requester, wherein the resource invocation instructions are used to point to a unique identifier of the target information unit; The target metadata directory is retrieved based on the unique identifier, and the sensitivity level parameters of the target information units corresponding to the target metadata directory are parsed. Based on the sensitivity level parameters, a preset control benchmark template is determined, and the control benchmark template is parameterized and evolved by combining dynamic context factors and contractual constraint rules to obtain an instantiated control instruction set. According to the control instruction set, the target information unit is sequentially subjected to attribute replacement and encoding enhancement processing, and an isolation strategy mark is attached after processing. The isolation strategy mark is used to indicate the target's operating isolation level. Based on the isolation strategy marker, an isolation zone instance of the corresponding level is constructed in a restricted computing environment supported by trusted hardware, and the processed target information unit is transmitted to the isolation zone instance; The target information unit is read through the isolation zone instance, and a unique traceability identifier, trace_id, is associated in the corresponding reading result. The trace_id is generated in the policy orchestration engine and consists of at least the requester's decentralized identifier, the target information unit identifier, a random factor, and a time series. The trace_id is loaded into the metadata field and frequency domain feature of the read result in a dual-elemental embedding manner, so that the two share the same identifier mapping; An output record is generated based on the trace_id, and an immutable digest of the output record is transmitted to the target distributed ledger evidence storage system.

2. The medical data security processing method based on dynamic strategies according to claim 1, characterized in that, Loading the trace_id into the frequency domain features of the read result in a dual-cube manner includes: The read results to be injected are standardized into a pixel matrix representation; The pixel matrix is ​​divided into several DCT blocks according to a fixed block size, wherein the block size is N×N blocks, where N is an integer that satisfies a preset computational complexity constraint, and the value of N ranges from 4 to 16. Perform a two-dimensional discrete cosine transform on the DCT block to obtain the frequency domain coefficient matrix; The embedded key is obtained by hash calculation based on the trace_id and the pre-acquired system salt value; The intermediate frequency coefficients used for embedding in the DCT block are determined based on the embedding key; The trace_id is expanded into a redundant bit string, and the redundant bit string is mapped bit by bit into several bit substrings; The redundant bit string is embedded into the intermediate frequency coefficients according to the bit substring.

3. The medical data security processing method based on dynamic strategies according to claim 1, characterized in that, Loading the trace_id into the metadata field of the read result in a dual-cubing manner includes: Construct the payload to be embedded. The payload includes at least: trace_id, generator identifier, timestamp, version number, and checksum for integrity verification. Error correction coding is performed on the payload, and the result of the error correction coding is compressed to obtain a compressed result; The compression result is symmetrically encrypted based on the pre-shared system key to obtain the target byte string, and the target byte string is then encoded in a transmissible manner to obtain the encoded string; A steganographic field is derived from the trace_id, and the encoded string is written into the steganographic field.

4. The medical data security processing method based on dynamic strategies according to claim 3, characterized in that, Deriving a steganographic field based on the trace_id and writing the encoded string into the steganographic field includes: The encoded string is divided into m segments, where m is an integer greater than or equal to 2, and the length of each segment is a preset length; A seed is generated based on the trace_id and the pre-acquired system salt value, and the pseudo-random sequence generator is initialized with the seed; A pseudo-random sequence is generated by the pseudo-random sequence generator, and the pseudo-random sequence is used to determine the write position of the m slices; The fragments are written to the writing positions according to the pseudo-random sequence, and an imperceptible encoding perturbation is embedded in the corresponding field information.

5. The medical data security processing method based on dynamic strategies according to claim 1, characterized in that, The process involves determining a preset control baseline template based on the sensitivity level parameters, and then parameterizing and evolving the control baseline template using dynamic context factors and contractual constraint rules to obtain an instantiated control instruction set, including: Based on the sensitivity level parameters, determine the control benchmark template corresponding to the sensitivity level; Collect dynamic context factors related to the resource invocation command; The contract execution module is invoked to parse the corresponding contractual constraint rules from the pre-configured digital contract. These contractual constraint rules are used to limit additional access conditions. The dynamic context factor and the contractual constraint rule are input into the management baseline template, and the parameter fields in the management baseline template are updated to obtain the management configuration; The control configuration is converted into an instantiated control instruction set.

6. The medical data security processing method based on dynamic strategies according to claim 1, characterized in that, The step involves reading the target information unit through the isolation zone instance and associating a unique traceability identifier (trace_id) with the corresponding reading result. The trace_id is generated in the policy orchestration engine and consists of at least the requester's decentralized identifier, the target information unit identifier, a random factor, and a time series, including: In the isolated zone instance, the restricted access interface is invoked to perform a read operation on the target information unit, generating corresponding plaintext information; A temporary buffer is established in the isolation zone instance, and the plaintext information is written into the temporary buffer; The DID and target information unit identifier are obtained through the strategy orchestration engine, and hash values ​​are calculated respectively to obtain the first hash value and the second hash value; A random factor is generated using a secure random number generator, and a high-precision system clock is invoked to collect time series information. The first hash value, the second hash value, the random factor, and the time series are concatenated into a base string, and the base string is encoded to generate a globally unique trace identifier, trace_id.

7. The medical data security processing method based on dynamic strategies according to claim 1, characterized in that, Before reading the target information unit through the isolation zone instance and associating a unique traceability identifier (trace_id) with the corresponding reading result, wherein the trace_id is generated in the policy orchestration engine and consists of at least the requester's decentralized identifier, the target information unit identifier, a random factor, and a time series, the method further includes: In the isolated zone instance, a secure random number generator is invoked to generate a physical random number sequence; The first random factor is generated based on a preset seed using a pseudo-random number generator; The physical random number sequence is combined with the first random factor by an entropy fusion operation to obtain the second random factor; The strategy orchestration engine generates a trace_id based on the second random factor.

8. A medical data security processing device based on dynamic strategies, characterized in that, The device includes: The instruction receiving unit is used to receive a resource invocation instruction carrying a decentralized identifier of the requester through a policy orchestration engine. The resource invocation instruction is used to point to a unique identifier of the target information unit. The parsing unit is used to retrieve the target metadata directory based on the unique identifier and parse the sensitivity level parameters of the target information units corresponding to the target metadata directory; The instruction generation unit is used to determine a preset control benchmark template based on the sensitivity level parameters, and to perform parameterized evolution of the control benchmark template in combination with dynamic context factors and contractual constraint rules to obtain an instantiated control instruction set. The encoding conversion unit is used to perform attribute replacement and encoding enhancement processing on the target information unit in sequence according to the control instruction set, and to attach an isolation policy mark after processing. The isolation policy mark is used to indicate the target's operating isolation level. An isolation zone construction unit is used to construct an isolation zone instance of the corresponding level in a restricted computing environment supported by trusted hardware based on the isolation policy marking, and to transmit the processed target information unit to the isolation zone instance; The ID generation unit is used to read the target information unit through the isolation zone instance and associate a unique traceability identifier, trace_id, in the corresponding reading result. The trace_id is generated in the policy orchestration engine and consists of at least the requester's decentralized identifier, the target information unit identifier, a random factor, and a time series. The ID embedding unit is used to load the trace_id into the metadata field and frequency domain feature of the reading result in a dual embedding manner, so that the two share the same identifier mapping; The transmission unit is used to generate an output record based on the trace_id and transmit the immutable digest of the output record to the target distributed ledger evidence storage system.

9. A medical data security processing device based on dynamic strategies, characterized in that, The device includes: Processor, memory, input / output units, and bus; The processor is connected to the memory, the input / output unit, and the bus; The memory stores a program, which the processor invokes to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains a program that, when executed on a computer, performs the method as described in any one of claims 1 to 7.

Images