Method, device, medium and product for data discovery and privacy computing oriented to medical scientific research data space

Abstract

The application discloses a medical research data space-oriented data discovery and privacy computing cooperation method, device, medium and product; the method comprises the following steps: establishing a contract unique identifier for medical research data; opening data structure information of medical research data not containing real data entities to a data user; generating sample data corresponding to the medical research data, and providing the sample data to the data user after opening the data structure information; receiving a probe condition input by the data user on the sample data, and associating the probe condition to the contract unique identifier; converting the probe condition associated with the contract unique identifier into a data delivery range; after the contract takes effect, performing a real query operation on original real data corresponding to the medical research data according to the contract unique identifier and the data delivery range, obtaining real data results, and connecting the real data results to a data space privacy computing platform; and the safety of the medical research data is ensured.

Description

Technical Field

[0001] This application relates to the field of privacy computing, and in particular to a collaborative method, device, medium, and product for data discovery and privacy computing in the medical research data space. Background Technology

[0002] Currently, most technologies related to medical research data collaboration adopt the following categories: one is a data exchange platform or research data sharing platform that focuses on resource publishing, protocol negotiation, and data transmission; another is a medical data cleaning platform or privacy computing platform that focuses on project collaboration, node mutual trust, and secure computing; in addition, there are sample display and data sampling tools that provide a small number of example records, as well as page configuration tools for constructing exploration interfaces and rule configurations.

[0003] However, the aforementioned technical solutions have several shortcomings in medical research data scenarios. First, existing exploration processes often directly or indirectly expose real data entities. Even with a limit on the number of data entries explored, the returned data is still just real data records or partial fields, posing significant privacy risks in medical scenarios such as medical records and diagnoses. Second, the exploration and delivery processes lack a progressive hierarchical mechanism, often employing only a binary distinction of allowing or disallowing exploration, making it difficult for data users to assess data value without violating security boundaries. Furthermore, existing sample data generation rules are usually fixed templates, lacking customization capabilities; and the generated sample data differs significantly from the real resource field structure or enumerated value range, making query conditions configured on sample data unsuitable for direct execution on real data. Additionally, existing contract agreements, exploration processes, and privacy computing platform table entry stages typically use independent numbering, lacking a unified main identifier for association, easily leading to business chain breaks and difficulties in traceability. Moreover, after the contract takes effect, many existing systems still allow data consumers to download or preview real data, failing to implement a strict protection mechanism where real data can only enter a secure execution environment. For medical data consisting of multiple tables, existing privacy-preserving computation platforms have a relatively simple input path, making it difficult to reliably deliver results for multi-table join queries. Finally, the existing system lacks a linkage mechanism between sample status and exploration authorization, and fails to promptly invalidate old samples after changes in the data source structure, which can easily lead to distorted exploration conclusions and mislead subsequent deliverables. Summary of the Invention

[0004] One objective of this application is to provide a collaborative method, device, medium, and product for data discovery and privacy computing in the medical research data space, at least to address the problems in the prior art where the exploration process directly or indirectly exposes real data entities, and the sample exploration conditions cannot be smoothly transferred to the real data execution environment, resulting in the real data still facing the risk of being illegally viewed and exported after the contract takes effect.

[0005] To achieve the above objectives, some embodiments of this application provide the following aspects:

[0006] Firstly, some embodiments of this application provide a collaborative method for data discovery and privacy computing in the medical research data space, the method comprising:

[0007] Establish unique contract identifiers for medical research data;

[0008] The data structure information of the medical research data, which does not contain real data entities, is made available to data users.

[0009] Generate sample data corresponding to the medical research data, and provide the sample data to the data user after opening the data structure information;

[0010] Receive the probe conditions input by the data user on the sample data, and associate the probe conditions with the unique identifier of the contract;

[0011] The exploration conditions associated with the unique identifier of the contract are converted into a data delivery scope;

[0012] After the contract takes effect, a real query operation is performed on the original real data corresponding to the medical research data according to the unique identifier of the contract and the scope of data delivery, to obtain the real data results, and the real data results are connected to the data space privacy computing platform.

[0013] Secondly, some embodiments of this application also provide an electronic device, the electronic device comprising: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method described above.

[0014] Thirdly, some embodiments of this application also provide a computer-readable medium having computer program instructions stored thereon, which can be executed by a processor to implement the method described above.

[0015] Fourthly, some embodiments of this application also provide a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the method described above.

[0016] Compared with related technologies, the solution provided in this application establishes a multi-level privacy-progressive discovery mechanism, enabling data users to obtain information step-by-step according to metadata, sample data, hit information, and formal execution results, avoiding direct contact with real row-level data entities throughout the process and ensuring the security of medical research data. Simultaneously, a configurable sample rule engine is constructed, supporting unified dynamic configuration of synthesis ratios, single-table limits, sensitive keywords, and logical rules to meet the differentiated security strength requirements of different medical institutions and research scenarios. Furthermore, by reusing the true value range of specific fields in the original real data and adopting a mandatory template generation mechanism for sensitive fields, the usability of sample data as a basis for exploration is balanced with the thoroughness of personal information anonymization.

[0017] Building upon this foundation, a unique contract identifier mechanism is established to unify and link the entire process—from exploration and negotiation to formal signing, actual execution, and privacy calculation and table entry—ensuring seamless data intent and results at any stage can be accurately used and retrieved in subsequent stages. This resolves the issue of disconnected business identifiers across multiple systems and stages. Furthermore, an executable constraint generation mechanism for data delivery scope is introduced. This directly transforms the field selections, filtering conditions, and relationships formed by data users on sample data into unified constraint objects for actual execution and platform table entry after signing. This ensures a high degree of consistency between sample exploration conditions and formal delivery conditions, achieving a smooth transition from exploration logic to the formal delivery process.

[0018] Furthermore, the output flow of the original real data is strictly limited. After the contract takes effect, queries on the original real data are only allowed within the provider's controlled environment, and the execution results are directly supplied to secure environments such as privacy computing platforms for analysis. Displaying the data on any visualization interface or allowing manual download is strictly prohibited, eliminating the risk of unauthorized browsing, exporting, and secondary dissemination of the real data entity after delivery. In addition, a linkage interception mechanism between sample status and exploration permissions, as well as a sample invalidation mechanism triggered by changes in the data source table structure, effectively ensures the accuracy of the sample exploration process and the timeliness of data delivery. Attached Figure Description

[0019] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0020] Figure 1 An exemplary flowchart of a collaborative method for data discovery and privacy computing in the medical research data space, provided in some embodiments of this application;

[0021] Figure 2A schematic diagram illustrating the sample generation of a collaborative method for data discovery and privacy computing in the medical research data space, provided in some embodiments of this application;

[0022] Figure 3 An exemplary structural diagram of the electronic device provided for some embodiments of this application. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] Figure 1 An exemplary flowchart of a collaborative method for data discovery and privacy computing in a medical research data space, provided for some embodiments of this application, is included in the method:

[0025] S101. Establish a unique contract identifier for medical research data.

[0026] Specifically, when medical institutions or other organizations publish structured medical research data to the Data Space Connector to form products, contract strategies, or allow external entities to initiate exploration negotiations, the system pre-establishes or assigns a unified business thread identifier, i.e., a unique contract identifier, to the relevant resources. The system generates this unique contract identifier immediately at the initial stage of exploration authorization establishment or resource negotiation. In subsequent exploration phases, the system uses the pre-established unique contract identifier to pre-bind the exploration behavior generated by the data user with preset conditions. When the data user confirms the screening intention and formally signs the contract, the system formally solidifies and finally binds the pre-assigned unique contract identifier with the final contract subject and the confirmed data delivery scope, and continues to use the unique contract identifier after formal signing. The system relies on the unique contract identifier to uniformly bind the initial exploration behavior, the determined delivery scope, the subsequent actual execution tasks, the privacy calculation objects, and the final audit records.

[0027] S102. Disclose the data structure information of the medical research data that does not contain real data entities to the data users.

[0028] Specifically, during the initial statistical discovery phase, data users can only obtain non-row-level information such as table structure, field names, field types, enumeration value ranges, null value rates, time ranges, sample status, and controlled statistical summaries. The system strictly limits the display of any actual record content to the outside world during this phase. Simultaneously, the user's interface browsing behavior, field selections, and preset conditions when obtaining the data structure information are all recorded in the context corresponding to the unique identifier of the contract.

[0029] S103. Generate sample data corresponding to the medical research data, and provide the sample data to the data user after opening the data structure information.

[0030] Specifically, once resources allow exploration and sample data is ready, the system automatically synthesizes non-real sample data based on pre-configured sample rules such as synthesis quantity rules, field type synthesis strategies, and sensitive field identification rules. Alternatively, the provider can manually import non-real sample data. Since the sample data has the same structure as real data but does not contain real individual information, the system grants data users access to explore the sample data, allowing them to perform operations such as exploration, pagination, sorting, filtering, and table join simulations using a conditional editor or query language editor.

[0031] S104. Receive the probe conditions input by the data user on the sample data, and associate the probe conditions with the unique identifier of the contract.

[0032] Specifically, when a data user performs related operations on the sample data, the system fully receives and records the probing actions. The specific recorded content includes the sample version used, the sample rule version, a summary of the filtering results, the saved field whitelist, and probing conditions such as table selection, and all of the aforementioned information is uniformly associated with the main line of the contract's unique identifier.

[0033] S105. Convert the exploration conditions associated with the unique identifier of the contract into a data delivery scope.

[0034] Specifically, when the data user confirms the generation of a formal delivery intention based on the exploration results, the system continues to use the unique contract identifier to transform the executable conditions accumulated during the exploration phase into unified executable constraint objects. The system receives exploration conditions including field selection, relationships, filtering conditions, and sorting rules, parses them into structured constraint objects, and verifies whether the generated structured constraint objects exceed the defined boundaries of the resources. The verified structured constraint objects are solidified into the data delivery scope and recorded in the main line corresponding to the unique contract identifier, serving as the formal objects uniformly invoked in subsequent stages.

[0035] S106. After the contract takes effect, according to the unique identifier of the contract and the scope of data delivery, perform a real query operation on the original real data corresponding to the medical research data to obtain the real data results, and connect the real data results to the data space privacy computing platform.

[0036] Specifically, after a formal contract is signed and authorization is established, the system locates the corresponding data delivery scope based on the unique identifier of the contract. It then directly performs genuine queries and extractions of the original, authentic data within the provider's controlled environment, without granting data users access to the visual browsing interface or table download permissions for the authentic data. The system processes the obtained authentic data results according to the principle of field minimization. Subsequently, based on the true structure of the original authentic data and the capabilities of the privacy computing platform, it adaptively selects delivery methods such as direct connection to a single database table, multi-table wide table transfer, or controlled file rollback, directly connecting the authentic data results to the data space privacy computing platform. This restricts data users to completing subsequent analysis and computation tasks only within the secure environment.

[0037] In this embodiment, by introducing a unique contract identifier, a unified business identifier is achieved across the entire chain, from early data exploration and formal signing to later actual execution and platform entry. Simultaneously, a multi-level, progressive discovery mechanism is adopted, first revealing data structure information and then providing non-real sample data. Combined with the transformation and solidification of the data delivery scope, this allows data users to accurately set exploration constraints without accessing actual row-level records, ensuring a seamless transition of exploration logic to the formal delivery process. Furthermore, after the contract takes effect, the output flow of original real data is strictly limited, allowing only the adaptive access of real query results to the data space privacy computing platform based on the data delivery scope. This constructs a closed-loop environment that does not expose real data entities before or after signing, significantly improving the security and compliance protection level during the flow of medical research data.

[0038] In one embodiment, the method employs a multi-level privacy-progressive data discovery mechanism; the multi-level privacy-progressive data discovery mechanism progressively opens controlled discovery permissions according to a preset privacy exposure level; before converting the exploration conditions associated with the unique identifier of the contract into the data delivery scope, the method includes:

[0039] The exploration conditions are applied to the original real data in accordance with the hierarchical control rules of the multi-level privacy progressive data discovery mechanism.

[0040] The system restricts the return of row-level records of the original real data to the data user and returns the execution status, number of hits, or controlled statistical summary to the data user.

[0041] Specifically, the collaborative method is based on a multi-level privacy-progressive data discovery mechanism. The system progressively grants controlled discovery capabilities to data users in stages, from low to high privacy exposure risk and from coarse to fine information availability. This multi-level privacy-progressive data discovery mechanism can be divided into four levels: controlled statistical discovery, sample data exploration, true hit verification, and privacy computation execution. In this mechanism, information generated at each level can be smoothly transferred to the next, with each level gaining more executable capabilities than the previous one, but never granting higher data visibility permissions to data users. The system ensures that no true row-level records are returned to data users at any stage before signing the agreement; only sample data exploration or controlled hit information is allowed.

[0042] The data structure information of the medical research data that is disclosed to data users without containing real data entities corresponds to the controlled statistical discovery level;

[0043] The sample data is provided to the data user, and the exploration conditions input by the data user on the sample data are received, corresponding to the exploration level of the sample data;

[0044] After the contract takes effect, according to the unique identifier of the contract and the scope of data delivery, a real query operation is performed on the original real data corresponding to the medical research data to obtain the real data results, and the real data results are connected to the data space privacy computing platform, corresponding to the privacy computing execution level;

[0045] Before converting the probe conditions associated with the unique identifier of the contract into a data delivery scope, the collaborative method further includes performing the true hit verification level: performing the probe conditions on the original true data within the provider's controlled environment, and returning the number of hits or a controlled statistical summary to the data user.

[0046] Taking the example of a data provider (e.g., a medical institution) providing "cardiovascular disease patient diagnosis and treatment data" as the original authentic data to a data user, the specific operation process of the multi-level privacy-progressive data discovery mechanism is as follows:

[0047] In the first stage, the controlled statistical discovery level, after logging into the system, a data user can only see the "Cardiovascular Disease Resources" section, which includes patient visit and diagnosis tables. The system displays field names such as diagnosis code, patient age, and visit date, as well as controlled statistical summaries such as "total of 100,000 records, average age of 65 years, and a null value rate of 5% for specific diagnosis fields." At this point, the data user cannot obtain any specific, actual patient medical records.

[0048] In the second stage, the sample data exploration level, a data user needs to write filtering logic to extract patients with specific characteristics. The system provides the user with a batch of non-real sample data automatically synthesized by rules. This sample data reuses real medical dictionary codes and includes virtual age values ​​generated according to statistical distributions. The user inputs exploration conditions such as "screen for patients with diagnostic codes of I20 (representing cardiovascular disease) and ages greater than fifty" into the sample data. After execution, the system returns dozens of sample query results. The user uses this to verify the logical correctness of the exploration conditions and the effectiveness of the table associations, without ever accessing real individual patient information.

[0049] In the third stage, the true hit verification stage, a data user wanted to confirm how many patients in the real medical database met the aforementioned search criteria before formally signing the contract. The system directly sent the search criteria written by the data user in the second stage to the real database of the medical institution for execution and returned statistical information to the data user: "Execution successful, 20,000 real records matched." At this stage, the data user confirmed that the available real data volume fully met the training requirements of the research model, but the system never showed the data user any real patient row-level records.

[0050] In the fourth stage, the privacy-enhancing computation execution stage, both parties formally signed an agreement based on the aforementioned hit verification results. The system continues to use a unique contract identifier, transforming the aforementioned exploration conditions into a fixed data delivery scope. Within the controlled environment of the medical institution, it performs queries on the original real data, extracting 20,000 real patient records. Subsequently, the system removes sensitive fields and directly and adaptively integrates the real patient records into the data space privacy-enhancing computation platform. A data user can only access the real patient records for algorithmic modeling or feature analysis within the privacy-enhancing computation platform; they cannot browse or download the real patient detail entity data through any manual interface.

[0051] Furthermore, in one embodiment, the data structure information includes at least one of table structure, field name, field type, enumeration value range, time range, null value rate, sample status information, and controlled statistical summary;

[0052] The controlled statistical summary is calculated based on the original real data.

[0053] Specifically, the data structure information disclosed by the system to data users is non-row-level information. During the initial discovery phase, data users can only obtain the aforementioned table structure, field names, field types, enumeration value ranges, null value rates, time ranges, sample statuses, and controlled statistical summaries; they cannot see any actual record content. The controlled statistical summaries are calculated based on the original real data. The system performs statistical calculations on the original real data in the background, extracting controlled statistical summaries based on dimensions such as total number of rows, value range, mean, standard deviation, and distribution ratio, and then displays these controlled statistical summaries to the data users.

[0054] Furthermore, in one embodiment, providing the sample data to the data user includes:

[0055] Grant access to the sample data to the data users;

[0056] The system receives the probe conditions executed by the data user on the sample data and returns at least one of the query results, pagination results, and join table simulation results obtained by executing the sample data.

[0057] Specifically, regarding granting access to the sample data to the data user, when medical research data is accessible and the corresponding sample data is ready, the system grants the data user operation permissions for the sample data. Regarding receiving the exploration conditions executed by the data user on the sample data and returning at least one of the query results, pagination results, and join table simulation results obtained by executing the query on the sample data, the system allows the data user to perform exploration operations on the sample data using a condition editor or a structured query language editor. The system receives the exploration conditions corresponding to the aforementioned operations, executes the aforementioned exploration conditions on the sample data, and then returns the sample query results, pagination results, and join table simulation results to the data user, without involving the reading and display of actual data throughout the entire process.

[0058] The above examples demonstrate that by verifying the actual execution of the exploration conditions on the original real data in a provider-controlled environment before generating the final data delivery scope, data users can confirm the validity of the exploration conditions and the matching scale of the real data in advance without obtaining any actual row-level data entities. This verification mechanism, which only returns the number of hits or a controlled statistical summary, avoids the problem of empty or unexpected delivery results due to blind contracting, while strictly adhering to the security bottom line of not exposing the original real data entities. Therefore, it effectively improves the reliability of the transformation from exploration logic to the formal data delivery scope while ensuring the privacy and security of medical research data.

[0059] In one embodiment, generating sample data corresponding to the medical research data includes:

[0060] Obtain the sample generation configuration parameters set for the medical research data. The sample generation configuration parameters include basic configuration, sensitive field identification and synthesis rule configuration, and advanced generation rule control configuration.

[0061] Based on the aforementioned basic configuration, determine the maximum number of rows to be merged in a single table and the maximum merging ratio, and dynamically calculate the number of sample rows in a single table.

[0062] According to the sensitive field identification and synthesis rules configuration, sensitive fields are masked for desensitization, format-preserving encryption, or generated randomly according to the rules to generate corresponding sample content, and synthesis strategies are set for non-sensitive fields according to the field type labels;

[0063] Logical constraint rules are set according to the advanced generation rule control configuration, and the true value range of specific fields in the original real data is reused to generate the sample data.

[0064] Specifically, such as Figure 2 As shown, the system can establish a unified configuration reading mechanism to obtain the aforementioned parameter set predefined for specific medical research application scenarios. The basic configuration is used to limit the overall scale and boundary parameters of sample data generation; the sensitive field identification and synthesis rule configuration is used to control the system's automatic identification and forced transformation behavior of high-risk fields through preset switch states and keyword lists; the advanced generation rule control configuration is used to enable or disable deep structural rules such as uniqueness constraints, null value control, field association, and data format, respectively.

[0065] Furthermore, in one embodiment, determining the maximum number of rows to be synthesized in a single table and the maximum synthesis ratio according to the basic configuration, and dynamically calculating the number of sample rows in a single table, includes:

[0066] The total number of rows of the original real data collected;

[0067] Calculate the product of the total number of rows and the maximum synthesis ratio;

[0068] The product is compared with the maximum number of rows in the single table synthesis, and the smaller value is selected as the intermediate calculation result.

[0069] The intermediate calculation result is compared with the preset lower limit of a single table, and the larger value is selected as the number of sample rows in the single table.

[0070] Specifically, the system can collect the total number of rows of the original real data corresponding to the medical research data, calculate the preliminary number of rows based on the maximum synthesis ratio, and compare the calculation result with the upper limit of the number of rows in a single table to determine the final number of sample rows in a single table. In medical resource scenarios involving multiple table associations, the system further adjusts the lower limit of a single table based on the table quantity parameter, and reduces the number of sample rows in each table proportionally when the total number of samples exceeds the set upper limit of the total resource quantity.

[0071] Subsequently, the system can automatically identify sensitive fields such as names, ID numbers, mobile phone numbers, medical record numbers, hospital admission numbers, or addresses based on field name keywords, field type tags, or industry tags. The system forcibly applies the aforementioned desensitization or random generation rules to the identified sensitive fields, blocking the mapping association between sample content and real individuals. At the same time, the system applies a synthesis strategy to general structure fields and business fields according to field type tags. For example, it randomly generates integer and floating-point number segments based on statistical distribution, maintains the original proportion for Boolean fields, and randomly generates date fields within a real time range.

[0072] The system sets logical constraints according to the advanced generation rule control configuration and reuses the true value range of specific fields in the original real data to generate the sample data. Following the aforementioned logical constraints, the system maintains the uniqueness of primary keys and unique fields, maintains the original null value rate, ensures that non-null fields are not empty, maintains the chronological order of dates, and maintains the consistency of the correspondence and numerical precision between code and name fields. Furthermore, the system extracts the real dictionary content of the enumeration classification field and medical code field from the original real data and uses this real dictionary content as the generation range for the corresponding fields. By combining the aforementioned constraints and the true value range, the system ultimately synthesizes the sample data whose structure is highly consistent with the real environment.

[0073] Furthermore, in one embodiment, setting logical constraint rules according to the advanced generation rule control configuration includes:

[0074] According to the aforementioned logical constraint rules, control the time logic between time fields, the numerical size dependency logic between numerical fields, and maintain the correspondence between medical codes and medical names.

[0075] Specifically, after enabling advanced generation rule control configuration, the system performs multi-dimensional deep logical verification during the synthesis of non-real sample data. Regarding the time logic between time fields, the system identifies various date or timestamp fields in the data structure, such as admission time, discharge time, or test report time, and enforces the sequential order of these time fields according to the aforementioned logical constraint rules to avoid generating abnormal records such as discharge time earlier than admission time. Regarding the numerical size dependency logic between numerical fields, the system identifies structured numerical fields with inherent dependencies and limits the size ratio or range relationship of these numerical fields during the synthesis process. To maintain the correspondence between medical codes and medical names, the system simultaneously processes diagnosis codes, surgical codes, examination item codes, and their corresponding diagnosis and item name fields. When generating sample content, the system strictly maintains the dictionary mapping state between a specific medical code and its corresponding standard medical name according to the aforementioned logical constraint rules, preventing code and name misalignment or combination confusion. Furthermore, the system also combines the aforementioned rules to simultaneously maintain strict consistency in date format, encoding format, and numerical precision.

[0076] In the above embodiments, by introducing sample generation configuration rules containing multi-dimensional parameters, flexible control over the non-real sample data generation process is achieved, meeting the strict compliance audit requirements of different medical institutions; by dynamically calculating the number of sample entries, the need for multi-table data exploration is balanced with the reasonable allocation of system computing resources; by forcibly applying random or de-identified generation rules to sensitive fields, the possibility of sample data restoring the real patient identity is completely cut off, ensuring core privacy and security; by setting deep logical constraint rules and reusing the real value range of specific fields, the business logic realism of the sample data is greatly improved, enabling the conditions and query statements written by the data user on the sample data to be accurately and seamlessly transferred to the real data execution environment after signing the contract, solving the technical problem that the traditional fixed de-identification template causes business logic to be untransferable due to excessive distortion.

[0077] In one embodiment, converting the probe conditions associated with the contract's unique identifier into a data delivery scope includes:

[0078] The exploration conditions are parsed into structured constraint objects, and the exploration conditions include at least one of field selection, table selection, association, filtering conditions, sorting rules, and structured query language statements;

[0079] Verify whether the structured constraint object exceeds the defined boundary of the medical research data;

[0080] The validated structured constraint objects are solidified into the data delivery scope and recorded in the main line corresponding to the unique identifier of the contract.

[0081] Specifically, the system receives various exploration intentions formed by data users during the exploration phase based on sample data or metadata. These exploration intentions are manifested in various ways, such as field selection operations, table selection operations, relational configurations, filter condition configurations, and sorting rule settings on the front-end interface, or structured query language statements directly written by the data user. After obtaining the aforementioned exploration conditions, the system uses a parsing engine to uniformly parse these conditions, extracting standard query and constraint elements, thereby generating structured constraint objects in a unified format.

[0082] After generating a structured constraint object, the system triggers compliance and boundary verification logic. Specific verification dimensions include determining whether the structured constraint object requests a non-existent field, whether it exceeds the range of available tables pre-configured by the provider, whether it violates the system's restrictions on highly sensitive fields, and whether the structured constraint object violates preset row extraction limits or field minimization requirements. Through these multi-dimensional verifications, the system intercepts non-compliant probing attempts, ensuring that the generated object fully complies with the provider's authorization constraints.

[0083] After determining that the structured constraint object has passed all validations, the system solidifies the state of the aforementioned structured constraint object, forming a formal data delivery scope. Subsequently, the system extracts the current contract unique identifier and writes the solidified data delivery scope into the business mainline record corresponding to the contract unique identifier. At this point, the data delivery scope is no longer limited to the temporary probing state on the front-end page, but has been transformed into a formal basis that can be repeatedly invoked and executed in subsequent real data execution and privacy computing platform table entry processes.

[0084] In this embodiment, by uniformly parsing and solidifying the diverse exploration conditions during the exploration phase into structured constraint objects, the discrepancy between the front-end page exploration operation and the back-end data extraction logic is successfully eliminated. Simultaneously, by performing multi-dimensional resource boundary checks and deeply binding them to the contract's unique identifier, the risk of obtaining data beyond the permitted scope or illegally extracting highly sensitive fields is effectively prevented. These steps enable the conditional intent formed by data users on non-real sample data to be directly transformed into unified executable constraints that can be seamlessly reused in subsequent actual execution and platform table entry. This solves the problem of the disconnect between exploration rules and formal delivery rules in the original solution, achieving precise and consistent control over the scope of medical research data delivery.

[0085] In one embodiment, connecting the real data results to the data space privacy computing platform includes:

[0086] Apply field minimization rules to the actual data results to remove sensitive fields or perform irreversible transformations on related fields.

[0087] The real data results are imported into the privacy computing platform by adaptively selecting the supply path according to the table structure of the original real data.

[0088] The supply path includes at least one of the following: a single-table database direct connection path, a multi-table wide table relay path, and a controlled file rollback path.

[0089] Specifically, after the system completes the actual query execution and obtains the actual data results in a controlled environment, it imposes strict field minimization constraints on the result set. The system first identifies sensitive fields contained in the actual data results and directly removes specific sensitive fields that do not need to enter the privacy computing platform. Simultaneously, for association fields that must be used for data union or table join calculations but are not allowed to enter the privacy computing platform in plaintext, the system enforces irreversible transformation operations. These irreversible transformation operations include tokenization, hashing, or de-identification substitution, ensuring that the data subject entering the subsequent analysis environment cannot be reverse-engineered and reconstructed.

[0090] Based on the structural characteristics of the original real data and the capabilities of the privacy computing platform it interfaces with, the system dynamically determines and automatically matches the optimal data supply path. If the original real data is a single-table database structure and the receiving platform supports a direct database connection mechanism, the system selects the single-table direct database connection path, directly registers the data source object, and completes the table entry authorization process. If the processing scenario involves multi-table, multi-condition, and multi-field joint operations, the system selects the multi-table wide table relay path, pre-organizes and concatenates the query results into a unified format wide table structure on the data provider side, and then imports the wide table structure as a whole into the target platform. If the direct database connection and wide table relay methods are not feasible due to network, system architecture, or platform limitations, the system downgrades to the controlled file fallback path, packages the real data results in a controlled environment and converts them into a file format allowed by the privacy computing platform, and then completes the table entry operation in the form of a controlled file. Regardless of which supply path the system ultimately uses, the actual data results will not be displayed to the human-computer interaction interface of the data user. Instead, they will be directly imported into the privacy computing platform, limiting the data user to initiate statistical, modeling, and analysis tasks only within the privacy computing platform.

[0091] In this embodiment, by imposing strict field minimization rules and irreversible transformation operations, the channels for plaintext leakage of highly sensitive fields are cut off, significantly enhancing data security before medical data is imported into the external computing environment. Furthermore, considering the complex nature of medical research data, which often consists of multiple tables, the system provides adaptive and diversified table input paths, effectively overcoming the problems of unstable supply of multi-table join query results, inconsistent field correspondences, and excessively high platform adaptation complexity caused by a single table input channel. The introduction of the aforementioned adaptive supply mechanism ensures that real medical research data with different table structures and dimensions can be smoothly and stably accessed by the data space privacy computing platform through the most suitable underlying channel, thereby providing a reliable data supply guarantee for the efficient execution of subsequent model training and statistical analysis tasks.

[0092] In one embodiment, after the real data results are connected to the data space privacy computing platform, the method includes:

[0093] Receive a traceability request based on the unique identifier of the contract;

[0094] Based on the unique identifier of the contract, reverse lookup is performed to obtain the sample exploration records associated with the unique identifier of the contract, the scope of data delivery, and the authorization records for importing into the privacy computing platform.

[0095] Specifically, during or after the execution of a collaborative analysis task in medical research, when faced with scenarios such as internal compliance reviews, external security audits, or tracing the source of collaborative disputes, the system receives traceability requests initiated by the original data provider, platform administrator, or regulatory body. These traceability requests input the unique contract identifier, which is consistently used throughout the entire data discovery and delivery process, as the core query credential into the system backend.

[0096] Upon receiving the tracing request, the system initiates a reverse lookup query in the system's underlying logs and record library, using the contract's unique identifier as the primary index. First, the system extracts the sample exploration records from the earlier data discovery phase to precisely pinpoint the sample version, sample rule version, specific exploration actions, and preliminary field whitelist used by the data user. Then, the system extracts the data delivery scope solidified after the confirmation and signing of rights to clarify the table selection constraints, filtering conditions, and actual field minimization strategies applied during the actual query execution. Finally, the system obtains the authorization records connected to the privacy computing platform, covering privacy computing project information, node information, table structure version, and platform-side task flow records. The system then concatenates and summarizes the aforementioned record information covering multiple stages of exploration, delivery, and execution, thereby outputting a complete tracing chain report to the entity that initiated the tracing request.

[0097] In this embodiment, by retaining and providing reverse traceability capabilities based on unique contract identifiers after the import of real data, the entire lifecycle audit chain of medical research data is completely opened up, from the initial structure discovery, sample exploration, and intent transformation into formal data delivery scope, to the final execution and table entry within a controlled privacy computing platform. The aforementioned reverse traceability mechanism ensures that the legality and boundary compliance of each medical research collaborative analysis can be finely verified, enabling medical data providers to trace the basis for the extraction of underlying real data and the corresponding original exploration intent at any time. This effectively solves the technical problem of the disconnect between exploration page behavior and actual task execution in traditional multi-system cross-platform collaboration, making it difficult to accurately track and map the data. Consequently, it significantly improves the security, credibility, and post-event supervision efficiency of the medical data element circulation system.

[0098] In one embodiment, providing the sample data to the data user further includes:

[0099] Obtain the status identifier of the sample data;

[0100] In response to the status flag being in a ready state, grant the data user access to explore the sample data.

[0101] In response to a change in the source table structure of the medical research data, the status identifier is changed to an invalid state, and exploration operations on the sample data are restricted.

[0102] Specifically, before presenting or providing access to the data user, the system continuously monitors the internal attribute status of the sample data corresponding to the current medical research data. Only when the resource has completed the automatic synthesis or manual import of non-real sample data, and the current sample structure is completely consistent with the resource-level architecture, does the system determine that the sample data is available for the data exploration page and marks the status as ready. During the contract or product release phase, if the sample data has not yet been generated or is in an incomplete state, the system will impose linked restrictions on exploration authorization, such as graying out or blocking the interactive options that allow exploration, to avoid reverting to the real data exploration path when the sample is not ready. Only after strictly confirming that the status is ready will the system truly open exploration permissions and the condition editor entry for the sample data to the data user.

[0103] Throughout the entire lifecycle of medical research data collaboration and circulation, the system continuously monitors the underlying table structure status of the original real data. If the system detects structural changes in the source table, such as adding or deleting fields, modifying field types, or creating a new table, it determines that the original sample data can no longer correctly or securely support the current exploration process. At this point, the system immediately changes the original status flag from ready to invalid. Along with the forced change of the status flag, the system simultaneously cuts off the data user's access to the old version of the sample data, intercepts and restricts all subsequent exploration operations based on the old version of the sample data, and generates a prompt task to the data provider requiring the resynthesis of the sample data until sample data adapted to the new table structure is generated and the system re-enters the ready state.

[0104] In this embodiment, a strict linkage and interception mechanism between sample status identifiers and exploration authorization is established to prevent the forced opening of exploration operations when non-real samples are not properly prepared or have failed to be generated. This fundamentally eliminates the security risks of data consumers encountering abnormal prompts or system defenses degrading to the real data path after entering the exploration page, and clarifies the security boundaries of the early exploration phase. Simultaneously, by introducing a sample data invalidation mechanism triggered by changes in the source table structure, the possibility of old version sample data being used for unauthorized exploration after changes in the underlying architecture is completely blocked. The aforementioned mechanism effectively prevents the distortion of exploration conclusions caused by the disconnect between sample data and the real data structure, avoids misaligned exploration logic misleading the subsequent formal delivery stage, and ensures that the exploration conditions written by data users are always based on the latest and most accurate data architecture. This provides a reliable pre-emptive guarantee for efficient connection and accurate table entry in medical research collaboration.

[0105] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0106] Furthermore, some embodiments of this application also provide an electronic device. The electronic device can be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device can also be various forms of mobile devices, such as cellular phones, smartphones, wearable devices, and other similar computing devices.

[0107] The electronic device includes: one or more processors; and a memory storing computer program instructions that, when executed, cause the processor to perform the steps of the methods provided in any one or more of the above embodiments. Figure 3 An exemplary structural diagram of the electronic device is disclosed. The electronic device includes one or more processors 1101, a memory 1102, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0108] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103 and output device 1104 may be connected by a bus or other means, as shown in the figure, which is connected by a bus.

[0109] Input device 1103 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 1104 may include a display device, auxiliary lighting device (e.g., LED), and haptic feedback device (e.g., vibration motor). The display device may include, but is not limited to, a liquid crystal display, a light-emitting diode display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0110] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback); and input from the user can be received in any form (e.g., voice input or tactile input).

[0111] In this embodiment, a computer-readable medium stores a computer program / instructions that, when executed by a processor, implement the steps of the methods provided in any one or more of the above embodiments. This computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into that device. The aforementioned computer-readable medium carries one or more computer-readable instructions.

[0112] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0113] The memory 1102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 1102 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1102 may optionally include memory remotely located relative to the processor 1101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0114] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0115] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technologies, read-only optical discs, digital versatile optical discs or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0116] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0117] In the above embodiments, all or part of the implementation can be achieved through software, hardware, firmware, or any combination thereof. For example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the above steps or functions. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. In addition, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0118] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0119] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0120] The scope of this application is defined by the appended claims rather than the foregoing description, and is therefore intended to encompass all variations falling within the meaning and scope of equivalents of the claims. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device in software or hardware. Terms such as "first," "second," etc., are used only for distinguishing descriptions and do not indicate any particular order, nor should they be construed as indicating or implying relative importance.

[0121] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims, and the above embodiments should be regarded as exemplary and non-limiting.

Claims

1. A collaborative method for data discovery and privacy computing in medical research data space, characterized in that, The method includes: Establish unique contract identifiers for medical research data; The data structure information of the medical research data, which does not contain real data entities, is made available to data users. Generate sample data corresponding to the medical research data, and provide the sample data to the data user after opening the data structure information; Receive the probe conditions input by the data user on the sample data, and associate the probe conditions with the unique identifier of the contract; The exploration conditions associated with the unique identifier of the contract are converted into a data delivery scope; After the contract takes effect, according to the unique identifier of the contract and the scope of data delivery, a real query operation is performed on the original real data corresponding to the medical research data to obtain the real data results, and the real data results are connected to the data space privacy computing platform. The process of generating sample data corresponding to the medical research data includes: Obtain the sample generation configuration parameters set for the medical research data. The sample generation configuration parameters include basic configuration, sensitive field identification and synthesis rule configuration, and advanced generation rule control configuration. Based on the aforementioned basic configuration, determine the maximum number of rows to be merged in a single table and the maximum merging ratio, and dynamically calculate the number of sample rows in a single table. According to the sensitive field identification and synthesis rules configuration, sensitive fields are masked for desensitization, format-preserving encryption, or generated randomly according to the rules to generate corresponding sample content, and synthesis strategies are set for non-sensitive fields according to the field type labels; Logical constraint rules are set according to the advanced generation rule control configuration, and the true value range of specific fields in the original real data is reused to generate the sample data.

2. The method according to claim 1, characterized in that, The method employs a multi-level privacy-progressive data discovery mechanism; this mechanism progressively opens controlled discovery permissions according to preset privacy exposure levels; before converting the exploration conditions associated with the unique identifier of the contract into the data delivery scope, the collaborative method includes: The exploration conditions are applied to the original real data in accordance with the hierarchical control rules of the multi-level privacy progressive data discovery mechanism. The system restricts the return of row-level records of the original real data to the data user and returns the execution status, number of hits, or controlled statistical summary to the data user.

3. The method according to claim 1, characterized in that, The process of reusing the true value range of a specific field in the original real data to generate the sample data includes: Identify the enumerated classification fields and medical coding fields in the original real data; Collect the actual enumeration value range of the enumeration classification field and the actual encoding set of the medical coding field; The actual enumeration value range and the actual encoding set are applied to the generation process of the corresponding fields in the sample data.

4. The method according to claim 1, characterized in that, The step of connecting the real data results to the data space privacy computing platform includes: Apply field minimization rules to the actual data results to remove sensitive fields or perform irreversible transformations on related fields. The real data results are imported into the privacy computing platform by adaptively selecting the supply path according to the table structure of the original real data. The supply path includes at least one of the following: a single-table database direct connection path, a multi-table wide table relay path, and a controlled file rollback path.

5. The method according to claim 1, characterized in that, Providing the sample data to the data user further includes: Obtain the status identifier of the sample data; In response to the status flag being in a ready state, grant the data user access to explore the sample data. In response to a change in the source table structure of the medical research data, the status identifier is changed to an invalid state, and exploration operations on the sample data are restricted.

6. The method according to claim 1, characterized in that, After the real data results are connected to the data space privacy computing platform, the method includes: Receive a traceability request based on the unique identifier of the contract; Based on the unique identifier of the contract, reverse lookup is performed to obtain the sample exploration records associated with the unique identifier of the contract, the scope of data delivery, and the authorization records for importing into the privacy computing platform.

7. An electronic device, characterized in that, The electronic device includes: One or more processors; and A memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method as described in any one of claims 1 to 6.

8. A computer-readable medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 6.

9. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 6.

Images