A system and method for sharing rare disease data

Abstract

The application provides a rare disease data sharing system and method, and relates to the technical field of medical treatment. The sharing system comprises a server and a plurality of clients respectively deployed in different medical institutions and different departments. The server and the clients are connected to form a medical data platform based on a federated learning mechanism. The server searches based on case characteristics uploaded by each client, determines case characteristics extracted from a plurality of medical data of a patient to be analyzed, and then analyzes through a rare disease analysis model to assist doctors in judging the disease. The privacy of the patient's medical data can be ensured, and the patient does not need to manually organize or provide previous case materials, which provides convenience for doctors and patients.

Description

Technical Field

[0001] This application relates to the field of medical technology, and more specifically, to a system and method for sharing rare disease data. Background Technology

[0002] In current technology, patients with rare diseases typically need to receive treatment at multiple different medical institutions. This need stems from the complexity and variability of rare diseases. Due to the extremely low incidence of rare diseases, their symptoms and treatment plans are often highly specialized and specific, thus patients may need to seek treatment from multiple experts in different fields. However, because patient data involves personal privacy protection, effective information sharing between different medical institutions is difficult. Although modern information technology can support data storage and management to some extent, in practice, due to the strict protection of personal privacy rights and the requirements of relevant laws and regulations, the cross-institutional transmission and sharing of medical data still faces many obstacles. This results in a lack of complete historical medical information even among different medical records of the same patient, affecting the doctor's overall judgment and diagnostic efficiency, and increasing the risk of misdiagnosis or missed diagnosis. In addition, due to the lack of a unified data management platform, patients and their families often need to manually organize and provide previous medical records, which also increases the inconvenience and complexity of the medical process. Summary of the Invention

[0003] The purpose of this application is to provide a rare disease data sharing system and method. Based on the federated learning mechanism, the server searches based on the case features uploaded by each client to determine the case features extracted from multiple medical records of the patient to be analyzed. Then, it analyzes the data through a rare disease analysis model to assist doctors in making disease judgments. This can ensure the privacy of patients' medical data while eliminating the need for patients to manually organize or provide previous medical records, thus providing convenience for both doctors and patients.

[0004] In a first aspect, the present invention provides a rare disease data sharing system. The sharing system includes a server and multiple clients deployed in different medical institutions and departments. The server responds to received data sharing requests, which at least include the data type of the patient's case to be analyzed. Based on the data type, a pre-trained rare disease analysis model is determined from the database. The server distributes the feature extractor of the rare disease analysis model to all clients. Each client uses the received feature extractor to extract features from the medical data of all patients stored locally to obtain corresponding case features. Each client sends all extracted case features to the server. The server identifies multiple target case features matching the patient to be analyzed from all received case features. The server feeds back the target case features and the classifier of the rare disease analysis model to the client that sent the data sharing request. The client that sent the data sharing request inputs the target case features and the preset case features of the patient to be analyzed into the classifier to obtain the multi-stage analysis results of the patient to be analyzed output by the classifier, in order to assist in determining the final rare disease diagnosis result of the patient to be analyzed.

[0005] In an optional implementation, the server determines multiple target case features that match the patient to be analyzed in the following way: based on the repetition value of each case feature, a corresponding first case feature set is determined; in the first case feature set, multiple target case features that match the preset case features of the patient to be analyzed are determined.

[0006] In an optional implementation, the server determines the first set of case features by: calculating the similarity between each case feature uploaded by the client sending the data sharing request and each case feature uploaded by other clients to determine the first number of times each case feature appears across different clients; calculating the similarity between each case feature uploaded by the client sending the data sharing request and other case features to determine the second number of times each case feature appears on the client sending the data sharing request; calculating a repetition value for any case feature based on the corresponding first and second number of repetitions; and adding case features with repetition values ​​greater than a preset value to the first set of case features.

[0007] In an optional implementation, the case features include multiple case feature matrices, and the server calculates the similarity between any two case features in the following way:

[0008] Each case feature matrix is ​​divided into multiple sub-matrices; for any two case features at the same position in the sub-matrices, at least one pair of target values ​​at the same position is randomly determined; it is determined whether each pair of target values ​​is the same value; the ratio between the number of target value pairs with the same value and the total number of target value pairs is calculated as the similarity.

[0009] In an optional implementation, the server determines multiple target case features that match preset case features of the patient to be analyzed in the following way:

[0010] Cluster all sample case features in the first case feature set with the preset case features to obtain the class in which the preset case features belong; use the sample case features in the class as the target case features.

[0011] In an optional implementation, the server clusters all sample case features in the first case feature set with preset case features in the following way:

[0012] The process involves: identifying preset case features and multiple sample case features as cluster centers; assigning sample case features to each cluster center based on the distance between each sample case feature and the cluster center to generate a corresponding class; determining whether each class meets the splitting condition; if the splitting condition is met, adding a cluster center and returning to the step of assigning sample case features to each cluster center to generate a corresponding class; if the splitting condition is not met, updating the cluster centers other than the preset case features; and determining whether the specified number of iterations has been reached. If not, returning to the step of assigning sample case features to each cluster center to generate a corresponding class.

[0013] In an optional implementation, the server determines whether each category meets the splitting conditions using the following methods:

[0014] For each class, calculate the mean and standard deviation of all case features in that class; calculate the distance between the mean and each case feature in that class, and determine whether the maximum distance is greater than a preset distance; and determine whether the standard deviation is greater than a preset standard deviation; if the maximum distance is greater than the preset distance and the standard deviation is greater than the preset standard deviation, then the class is determined to meet the splitting condition.

[0015] Secondly, the present invention provides a method for sharing rare disease data, applicable to a server. The method includes responding to a received data sharing request, the data sharing request including at least the data type of the patient's case to be analyzed; determining a pre-trained rare disease analysis model from a database based on the data type; distributing the feature extractor of the rare disease analysis model to all clients; the server determining multiple target case features matching the patient to be analyzed from all received case features; and feeding back the target case features and the classifier of the rare disease analysis model to the client that sent the data sharing request.

[0016] Thirdly, the present invention provides a method for sharing rare disease data, applicable to multiple clients deployed in different medical institutions and departments. The method includes sending a data sharing request to the server or responding to data sharing requests sent by other clients; extracting features from the medical data of all patients stored locally using a received feature extractor to obtain corresponding case features; and sending all extracted case features to the server.

[0017] In an optional implementation, the method further includes inputting the target case features and the preset case features of the patient to be analyzed into a classifier, and obtaining the multi-stage analysis results of the patient to be analyzed output by the classifier to help determine the final rare disease diagnosis result of the patient to be analyzed.

[0018] This application provides a rare disease data sharing system. The system includes a server and multiple clients deployed in different medical institutions and departments. The server and clients are built into a medical data platform based on a federated learning mechanism. The server searches based on the case features uploaded by each client to determine the case features extracted from multiple medical records of the patient to be analyzed. Then, it analyzes the data through a rare disease analysis model to assist doctors in making disease judgments. This system can ensure the privacy of patients' medical data while eliminating the need for patients to manually organize or provide previous medical records, thus providing convenience for both doctors and patients. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of the structure of a medical data processing system provided in an embodiment of this application;

[0021] Figure 2A communication flowchart of a rare disease data sharing system provided in this application embodiment;

[0022] Figure 3 A flowchart illustrating the steps for determining a first case feature set as provided in an embodiment of this application;

[0023] Figure 4 A flowchart illustrating a clustering step of case features provided in this application embodiment;

[0024] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] First, the application scenarios of this application will be described. The technical solution of this application can be applied to data sharing and auxiliary diagnosis and treatment for patients with rare diseases.

[0026] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0027] Figure 1 This is a schematic diagram of the structure of a medical data processing system provided in an embodiment of this application. Figure 1 As shown, the medical data processing system can achieve model training based on the federated learning mechanism in the following ways.

[0028] The server distributes public keys during the task model process based on the medical data analysis request initiated by the target client.

[0029] The medical data analysis request is used to indicate the types of medical data and rare diseases that the medical institution corresponding to the target client wants to analyze. Multiple clients include the target client and other clients that join the medical data analysis request.

[0030] The target client here is the medical institution that initiated the medical data analysis request. After the medical data analysis request is sent to the server, the server will broadcast it to the clients corresponding to the remaining medical institutions within the mechanism.

[0031] The remaining medical institutions can choose whether to respond to the medical data analysis request and use their local medical data to help the target medical institution jointly train and generate an AI model.

[0032] The types of medical data here can include various formats such as images, medical records, written records, and gene sequences. Rare diseases can be categorized into multiple systems, such as hematological diseases, neurological diseases, cardiovascular diseases, urinary system diseases, endocrine system diseases, skeletal system diseases, respiratory system diseases, immune system diseases, digestive system diseases, ophthalmic diseases, dermatological diseases, pediatric diseases, and obstetric and gynecological diseases. Each system includes at least one disease; for example, respiratory diseases specifically include lymphangioleiomyomatosis, pulmonary alveolar proteinosis, and idiopathic pulmonary fibrosis.

[0033] The remaining medical institutions can choose whether to join the medical data analysis request of the target medical institution A based on their local medical data.

[0034] Then, the server can identify the target medical institution A and other medical institutions B, C, D, and E that have joined the medical data analysis request, and send the task model and public key to the respective clients of medical institutions A, B, C, D, and E.

[0035] Each client (sub-center) trains its own model based on the aligned samples. The trained model is then encrypted and sent back to the server (main center), where the server calculates the fitting function and loss to update the model parameters. The server then distributes the re-aggregated model parameters to each client, enabling each client to update its sub-center model until the minimum loss value is obtained, thus completing the training of the rare disease analysis model.

[0036] The rare disease analysis models here can be uniformly saved to the server or fed back to the client that initiated the medical data analysis request.

[0037] In one embodiment of this application, in order to further ensure the security of medical data, rare disease analysis models can be uniformly managed on the server side.

[0038] When a medical institution receives a suspected rare disease patient, directly accessing the patient's medical records and related information provided by the patient and their family is not only inconvenient but also incomplete, with the risk of data loss due to the passage of time. Although medical data is currently mostly stored electronically and backed up within each medical institution, the protection of patient data involves personal privacy, making direct sharing of patient cases between different institutions difficult. Therefore, this application proposes a rare disease data sharing system based on a medical data processing system.

[0039] Figure 2 This is a communication flowchart of a rare disease data sharing system provided in an embodiment of this application. Figure 2 As shown, the sharing of rare disease data can be achieved in the following ways:

[0040] S1. The target client initiates a data sharing request to the server.

[0041] The target client here can be deployed in a department of a medical institution. When it receives a patient suspected or diagnosed with a rare disease, it can initiate a data sharing request in order to determine whether the patient has a rare disease or to determine further treatment plans for the rare disease.

[0042] A data sharing request must include at least the data type of the patient's case to be analyzed. That is, a data sharing request could specify a particular image and / or a biochemical marker from a specific test and / or a gene sequence, etc.

[0043] In one specific embodiment, the data sharing request may indicate the data type of the patient's medical records to be tested, which may include text-based physical examination data, ophthalmological examination data, family medical history investigation data, genetic testing lists, blood testing lists, and may also include image-based pathological slide images of specified locations, etc.

[0044] S2. The server responds to the received data sharing request by broadcasting it to other clients to identify the other clients participating in this data sharing.

[0045] Other clients here can be clients deployed in different departments of the same medical institution as the target client, or clients deployed in the same or different departments of other medical institutions across regions or cities.

[0046] S3. The server determines the pre-trained rare disease analysis model from the database based on the data type. The server then distributes the feature extractor of the rare disease analysis model to all clients.

[0047] Here, the server can match the corresponding rare disease sharing model based on the data type indicated by the data sharing request.

[0048] It should be noted that the data type indicated by the target customer here usually corresponds to the input data type of the rare disease analysis model that was previously trained and generated.

[0049] The rare disease analysis model here can include a feature extractor and a classifier. The server distributes the feature extractor to various clients to extract features from each client's medical data.

[0050] S4. Each client extracts features from the medical data of all patients stored locally using the received feature extractor to obtain the corresponding case features.

[0051] For privacy protection, each client uses a feature extractor to extract features from all locally stored medical data. This means that each patient's medical records are anonymized. Specifically, this medical data refers to the patient's medical records, which include images, medical records, written records, gene sequences, and other medical data generated during a single visit.

[0052] S5. Each client sends all extracted case features to the server.

[0053] S6. The server identifies multiple target case features that match the patient to be analyzed from all received case features.

[0054] In step S6, the server can determine multiple target case characteristics that match the patient to be analyzed in the following ways:

[0055] First, based on the repetition values ​​of each case feature, a corresponding first case feature set is determined. This step can initially screen out patients with repeat visits. For example... Figure 3 As shown, the server can determine the first case feature set in the following ways:

[0056] S610. For each case feature uploaded by the client that sent the data sharing request, calculate the similarity between the case feature and each case feature uploaded by other clients to determine the first number of times each case feature appears across different clients.

[0057] Here, the multiple case features received by the server from the target client A can be represented as follows: Where na represents the number of patient medical records in the target client. The matrix of the ka-th case feature included in each case feature.

[0058] The multiple case features received by the server from the target client B can be represented as follows: Where nb represents the number of patient medical records in the target client. The kb-th case feature matrix is ​​included in each case feature.

[0059] Furthermore, for example, with and Taking the total similarity S between them as an example, it can be calculated using the following formula:

[0060]

[0061] Among them, s ka，kb for The similarity value between them, ω ka，kb For s ka，kbThe corresponding weighting coefficients, for Covariance between for The corresponding standard deviation for The corresponding standard deviation for The Euclidean value, for The Euclidean value.

[0062] For example, in one embodiment of this application, using Taking the similarity S between them as an example, it can be calculated in the following way:

[0063] Each case feature matrix is ​​divided into multiple sub-matrices. For any two case features at the same position in the sub-matrices, at least one pair of target values ​​at the same position is randomly selected. It is determined whether each pair of target values ​​has the same value. The ratio between the number of target value pairs with the same value and the total number of target value pairs is calculated as the similarity score.

[0064] For example, a pair of target values ​​are respectively The value "1" in the second row of the second column, and The value in the second row of the second column is "0". This indicates that the pair of target values ​​are not the same. Finally, the ratio can be calculated as the similarity between the feature matrices of the two cases.

[0065] It should be noted that, The dimensions of the matrices may be different. In this case, the matrix with the smaller dimension can be used as the standard to trim the matrix with the larger dimension, or to fill the matrix with the smaller dimension.

[0066] Next, based on the magnitude of the total similarity S between the case features corresponding to the target client and the case features uploaded by other clients, it can be determined whether the case features are repeated. If the total similarity S is greater than the preset value, the corresponding case feature is determined to have appeared once. Finally, the first number of repetitions for each case feature is determined.

[0067] It should be noted that since other clients include clients from different departments within the same medical institution as the target client, as well as clients from different medical institutions with the same or different departments, different preset values ​​can be set for determining duplicate occurrences. Preset values ​​can also be set based on the time interval between patient medical records; the shorter the time interval, the higher the preset value can be, which helps improve the accuracy of duplicate occurrence detection.

[0068] S611. For each case feature uploaded by the client that sent the data sharing request, calculate the similarity between the case feature and other case features to determine the second number of times each case feature appears on the client that sent the data sharing request.

[0069] In step S611, the step of counting the number of second repetitions can be similar to the step in S610.

[0070] S612. For any case characteristic, calculate the repetition value based on the corresponding first repetition count and second repetition count.

[0071] The repetition value here can be the sum or product of the first repetition count and the second repetition count.

[0072] S613. Add case features with repeat values ​​greater than the preset value to the first case feature set.

[0073] In step S613, it can be assumed that patients with case characteristics whose repetition values ​​are greater than the preset value have sought medical treatment multiple times in multiple departments of multiple hospitals and have a higher probability of having a rare disease.

[0074] (ii) In the first set of case features, identify multiple target case features that match the preset case features of the patient to be analyzed.

[0075] Next, from the first set of case features, multiple target case features that are similar to those of the patient to be analyzed are identified. An improved clustering-based algorithm is used here.

[0076] Specifically, the server can determine multiple target case features that match the preset case features of the patient to be analyzed in the following ways:

[0077] Cluster all sample case features in the first case feature set with the preset case features to obtain the class to which the preset case features belong. Use the sample case features in the class as the target case features.

[0078] like Figure 4 As shown, the server can cluster all sample case features in the first case feature set with the preset case features in the following way:

[0079] S620. Determine the cluster centers by pre-defined case characteristics and the characteristics of multiple sample cases.

[0080] Here, the preset case features are fixed cluster centers, while the features of other sample cases can be randomly selected initially.

[0081] S621. Based on the distance between the characteristics of each sample case and the cluster center, assign sample case characteristics to each cluster center to generate the corresponding class.

[0082] The distance here can be calculated using methods such as cosine similarity and Jaccard coefficient. The sample case features are then assigned to the class closest to the cluster center.

[0083] S622. Determine whether each type meets the splitting conditions.

[0084] In step S622, the server can determine whether each type meets the splitting condition in the following ways:

[0085] For each category, calculate the mean and standard deviation of all case characteristics within that category.

[0086] Calculate the distance between the calculated mean and the characteristics of each case in that class, and determine whether the maximum distance is greater than a preset distance value. Also determine whether the calculated standard deviation is greater than a preset standard deviation value.

[0087] If the maximum distance value is greater than the preset distance value and the calculated standard deviation value is also greater than the preset standard deviation value, then the class is determined to meet the splitting condition.

[0088] If the maximum distance value is greater than the preset distance value, and the calculated standard deviation is also greater than the preset standard deviation, it indicates that the case features in the current class are not uniform enough, and the number of cluster centers can be increased. The newly added cluster centers are the sample case features corresponding to the maximum distance value.

[0089] S623. If the splitting condition is met, add cluster centers and return to the step of assigning sample case features to each cluster center to generate the corresponding class.

[0090] S624. If the splitting condition is not met, update the cluster centers other than the preset case characteristics.

[0091] S625. Determine whether the specified number of iterations has been reached. If not, return to the step of assigning sample case features to each cluster center to generate the corresponding class.

[0092] After reaching the specified number of iterations, the preset case feature class can be output. The sample case features in this class can be considered as the case features corresponding to the historical medical records of the patients to be analyzed.

[0093] S7. The server feeds back the target case characteristics and the classifier of the rare disease analysis model to the client that sent the data sharing request.

[0094] S8. The client that sends the data sharing request inputs the target case features and the preset case features of the patient to be analyzed into the classifier, and obtains the multi-stage analysis results of the patient to be analyzed from the classifier output, so as to help determine the final rare disease diagnosis result of the patient to be analyzed.

[0095] The target client can use a classifier to analyze multiple case features corresponding to the patient being analyzed. These case features are extracted from the patient's medical records at the same or different medical institutions at different times. The multi-stage analysis results output by the classifier can assist doctors in diagnosing whether a patient has a rare disease or in judging the progression of the patient's condition.

[0096] This application provides a rare disease data sharing system. Based on a federated learning mechanism, the server searches for case features uploaded by each client to identify case features extracted from multiple medical records of the patient to be analyzed. These features are then analyzed using a rare disease analysis model to assist doctors in diagnosing the condition. This system ensures the privacy of patients' medical data while eliminating the need for patients to manually organize or provide previous medical records, thus providing convenience for both doctors and patients.

[0097] In one embodiment of this application, a method for sharing rare disease data is provided, applicable to a server. The method includes responding to a received data sharing request, the data sharing request including at least the data type of the patient's case to be analyzed; determining a pre-trained rare disease analysis model from a database based on the data type; distributing the feature extractor of the rare disease analysis model to all clients; the server determining multiple target case features matching the patient to be analyzed from all received case features; and feeding back the target case features and the classifier of the rare disease analysis model to the client that sent the data sharing request.

[0098] A method for sharing rare disease data is also provided, applicable to multiple clients deployed in different medical institutions and departments. The method includes sending a data sharing request to the server or responding to data sharing requests sent by other clients; extracting features from the medical data of all patients stored locally using the received feature extractor to obtain corresponding case features; and sending all extracted case features to the server.

[0099] In an optional implementation, the method further includes inputting the target case features and preset case features of the patient to be analyzed into a classifier, and obtaining the multi-stage analysis results of the patient to be analyzed output by the classifier to help determine the final rare disease diagnosis result of the patient to be analyzed.

[0100] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 5 As shown, the electronic device 500 includes a processor 510, a memory 520, and a bus 530.

[0101] The memory 520 stores machine-readable instructions executable by the processor 510. When the electronic device 500 is running, the processor 510 and the memory 520 communicate via the bus 530. When the machine-readable instructions are executed by the processor 510, they can perform the operations described above. Figure 1 The steps of a method for calculating the output torque of a vehicle shown in the method embodiment can be found in the method embodiment for specific implementation, and will not be repeated here.

[0102] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described actions. Figure 1 The steps of a method for calculating the output torque of a vehicle shown in the method embodiment can be found in the method embodiment for specific implementation, and will not be repeated here.

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

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

[0105] Furthermore, 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.

[0106] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0107] It should be noted that if the function is implemented as a software module 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 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, a server, or a 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.

[0108] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0109] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A system for sharing rare disease data, characterized in that, The sharing system comprises a server and a plurality of clients respectively deployed in different medical institutions and different departments, The server determines a pre-trained rare disease analysis model from a database based on the data type of the case of the patient to be analyzed in response to the received data sharing request; The server distributes the feature extractor of the rare disease analysis model to all the clients; Each client extracts features from all the medical data of the patients stored locally by using the received feature extractor to obtain corresponding case features; Each client sends the extracted case features to the server; The server determines a first case feature set from the received case features based on the repetition value of each case feature; The server clusters all the sample case features in the first case feature set with the preset case feature of the patient to be analyzed to obtain a class in which the sample case features are located, and takes the sample case features in the class as target case features; The server feeds back the target case features and the classifier of the rare disease analysis model to the client that sent the data sharing request; The client that sent the data sharing request inputs the target case features and the preset case feature of the patient to be analyzed into the classifier to obtain a plurality of stage analysis results of the patient to be analyzed output by the classifier, so as to assist in determining the final rare disease diagnosis result of the patient to be analyzed.

2. The system of claim 1, wherein, The server determines the first case feature set in the following manner: For each case feature uploaded by the client that sent the data sharing request, the server calculates the similarity between the case feature and each case feature uploaded by other clients to determine the first repetition number of each case feature between different clients; For each case feature uploaded by the client that sent the data sharing request, the server calculates the similarity between the case feature and other case features to determine the second repetition number of each case feature on the client that sent the data sharing request; For any case feature, the server calculates a repetition value based on the corresponding first repetition number and second repetition number; The server adds the case feature with a repetition value greater than a preset value to the first case feature set.

3. The system of claim 2, wherein, The case features comprise a plurality of case feature matrices, and the server calculates the similarity between any two case features in the following manner: The server divides each case feature matrix into a plurality of sub-matrices; For any two case features, the server randomly determines at least one pair of target values in the same position of the sub-matrices in the same position; The server determines whether each pair of target values is the same value; The server calculates the ratio between the number of pairs of target values with the same value and the total number of pairs of target values as the similarity.

4. The system of claim 1, wherein, The server clusters all the sample case features in the first case feature set with the preset case feature in the following manner: The server determines the preset case feature and a plurality of sample case features as clustering centers; The server assigns sample case features to each clustering center based on the distance between the sample case features and the clustering centers to generate a corresponding class; The server determines whether each class meets a splitting condition; If the split condition is met, the cluster center is increased, and the step of assigning sample case features to each cluster center to generate a corresponding class is returned; If the split condition is not met, the cluster center is updated except for the preset case feature; It is determined whether the specified number of iterations is reached, and if not, the step of assigning sample case features to each cluster center to generate a corresponding class is returned.

5. The system of claim 4, wherein, The server determines whether each class meets the split condition in the following way: For each class, the calculation mean and calculation standard deviation between all case features in the class are calculated; The distance value between the calculation mean and each case feature in the class is calculated to determine whether the maximum distance value is greater than the preset distance value; And determine whether the calculation standard deviation is greater than the preset standard deviation; If the maximum distance value is greater than the preset distance value, and the calculation standard deviation is greater than the preset standard deviation, it is determined that the class meets the split condition. 6.A method for sharing rare disease data, characterized by, The method is suitable for the server, and the method comprises: In response to the received data sharing request, the data sharing request at least includes the data type of the case of the patient to be analyzed, and the pre-trained rare disease analysis model is determined from the database based on the data type; The feature extractor of the rare disease analysis model is distributed to all clients; In the received all case features, based on the repetition value of each case feature, a corresponding first case feature set is determined; All sample case features in the first case feature set are clustered with the preset case feature of the patient to be analyzed to obtain the class in which the preset case feature is located, and the sample case features in the class are used as target case features; The target case features and the classifier of the rare disease analysis model are fed back to the client that sent the data sharing request.

Images