Rare disease data sharing system and method

Abstract

The invention 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 deployed in different medical institutions and different departments, and the server and the clients construct a medical data platform based on a federated learning mechanism. The server performs search based on the case features uploaded by each client, determines the case features extracted from the plurality of doctor seeing data of the patient to be analyzed, and further performs analysis through the rare disease analysis model to assist doctors in disease judgment, so that the privacy of the medical data of the patient can be ensured, and the accuracy of the patient seeing data is improved. A patient does not need to manually arrange or provide previous case data, and convenience is provided for doctors and patients.

Description

Technical Field

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

[0002] In the existing technology, patients with rare diseases usually need to receive diagnosis and treatment in multiple different medical institutions. This demand stems from the complexity and variability of rare diseases. Since the incidence of rare diseases is extremely low, their symptoms and treatment plans are often highly professional and specific, so patients may need to seek diagnosis and treatment from multiple experts in different fields. However, since patient data involves personal privacy protection, it is difficult to achieve effective information sharing between different medical institutions. Although modern information technology can support data storage and management to a certain extent, in actual operation, 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 leads to the lack of complete historical medical information even between different medical records of the same patient, which affects the doctor's overall judgment and diagnostic efficiency of the condition and increases 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 the embodiments of the present application is to provide a rare disease data sharing system and method. On the basis of the federated learning mechanism, the server searches based on the case features uploaded by each client, determines the case features extracted from multiple medical data of the patient to be analyzed, and then analyzes them through a rare disease analysis model to assist doctors in making disease diagnosis. While ensuring the privacy of the patient's medical data, there is no need for the patient to manually organize or provide previous case information, which provides convenience for both doctors and patients.

[0004] In a first aspect, the present invention provides a rare disease data sharing system, which includes a server and multiple clients deployed in different medical institutions and departments. The server responds to a received data sharing request, which includes at least the data type of the case of the patient to be analyzed, and determines a pre-trained rare disease analysis model from a database based on the data type; the server sends a feature extractor of the rare disease analysis model to all clients; each client extracts features from the medical data of all patients stored locally through the received feature extractor to obtain corresponding case features; each client sends all the extracted case features to the server; the server determines multiple target case features that match the patient to be analyzed from all the received case features; the server feeds back the target case features and the classifier of the rare disease analysis model to the client that sends the data sharing request; 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 multiple 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.

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

[0006] In an optional embodiment, the server determines the first case feature set in the following manner: for each case feature uploaded by the client that sends the data sharing request, calculate the similarity between the case feature and each case feature uploaded by other clients, so as to determine the first repetition number of each case feature between different clients; for each case feature uploaded by the client that sends the data sharing request, calculate the similarity between the case feature and other case features, so as to determine the second repetition number of each case feature on the client that sends the data sharing request; for any case feature, calculate the repetition value based on the corresponding first repetition number and second repetition number; add case features with repetition values ​​greater than a preset value to the first case feature set.

[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 manner:

[0008] Divide each case feature matrix into multiple sub-matrices; for any two case feature sub-matrices at the same position, randomly determine at least one pair of target values ​​at the same position; determine whether each pair of target values ​​has the same value; calculate the ratio between the number of target value pairs with the same value and the total number of target value pairs as the similarity.

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

[0010] All sample case features and preset case features in the first case feature set are clustered to obtain the class to which the preset case features belong; and the sample case features in the class are used as target case features.

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

[0012] Determine the preset case characteristics and multiple sample case characteristics as cluster centers; based on the distance between each sample case characteristic and the cluster center, assign the sample case characteristics to each cluster center to generate a corresponding class; determine whether each class meets the split condition; if the split condition is met, add the cluster center, and return to the step of assigning the sample case characteristics to each cluster center to generate the corresponding class; if the split condition is not met, update the cluster centers except the preset case characteristics; determine whether the specified number of iterations is reached, if not, return to the step of assigning the sample case characteristics to each cluster center to generate the corresponding class.

[0013] In an optional implementation manner, the server determines whether each category meets the splitting condition in the following manner:

[0014] For each class, calculate the calculated mean and calculated standard deviation between all case characteristics in the class; calculate the distance value between the calculated mean and each case characteristic in the class, and determine whether the maximum distance value is greater than the preset distance value; and determine whether the calculated standard deviation value is greater than the preset standard deviation value; if the maximum distance value is greater than the preset distance value and the calculated standard deviation value is greater than the preset standard deviation value, then determine that the class meets the splitting condition.

[0015] In a second aspect, the present invention provides a method for sharing rare disease data, which is applicable to a server, and the method includes responding to a received data sharing request, the data sharing request includes at least the data type of the case of the patient to be analyzed, and determining a pre-trained rare disease analysis model from a database based on the data type; sending a feature extractor of the rare disease analysis model to all clients; the server determines, from all received case features, multiple target case features that match the patient to be analyzed; 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] In the third aspect, the present invention provides a method for sharing rare disease data, which is suitable for multiple clients deployed in different medical institutions and departments. The method includes sending a data sharing request to a server, or responding to data sharing requests sent by other clients; performing feature extraction on the medical data of all patients stored locally through the received feature extractor to obtain corresponding case features; and sending all extracted case features to the server.

[0017] In an optional embodiment, the method further includes inputting target case characteristics and preset case characteristics of the patient to be analyzed into a classifier, and obtaining multiple stage analysis results of the patient to be analyzed output by the classifier to assist in determining the final rare disease diagnosis result of the patient to be analyzed.

[0018] The present application provides a rare disease data sharing system, which includes a server and multiple clients deployed in different medical institutions and departments. The server and the clients are constructed into a medical data platform based on a federated learning mechanism. The server searches based on the case features uploaded by each client, determines the case features extracted from multiple medical data of the patient to be analyzed, and then analyzes them through a rare disease analysis model to assist doctors in making disease judgments. While ensuring the privacy of the patient's medical data, the patient does not need to manually organize or provide previous case information, which provides convenience for both doctors and patients. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

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

[0021] Figure 2A communication flow chart of a rare disease data sharing system provided in an embodiment of the present application;

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

[0023] Figure 4 A flowchart of a clustering step of case characteristics provided in an embodiment of the present application;

[0024] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0025] First, the application scenario of the present application is described. The technical solution of the present application can be applied to data sharing of patients with rare diseases and auxiliary diagnosis and treatment of patients with rare diseases.

[0026] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

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

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

[0029] Among them, the medical data analysis request is used to indicate the types of medical data and rare diseases to be analyzed by the medical institution corresponding to the target client, and the multiple clients include the target client and other clients that join the medical data analysis request.

[0030] The target client here is the target medical institution that initiates 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 in the mechanism.

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

[0032] The medical data types here can include images, case forms, records, gene sequences, etc. Rare diseases can be divided into multiple systems, such as blood system diseases, nervous system diseases, cardiovascular system diseases, urinary system diseases, endocrine system diseases, skeletal system diseases, respiratory system diseases, immune system diseases, digestive system diseases, ophthalmic system diseases, skin system diseases, pediatric system diseases and obstetrics and gynecology system diseases. Each system includes at least one disease, such as respiratory system diseases, including lymphangioleiomyomatosis, alveolar proteinosis, and idiopathic pulmonary fibrosis.

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

[0034] Furthermore, the server can determine 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. It then encrypts and transmits the trained model back to the server (main center), which calculates the fitting function and loss to update the model parameters. The server sends the re-aggregated model parameters to each client, which updates the sub-center model until the minimum loss value is obtained, completing the training of the rare disease analysis model.

[0036] The rare disease analysis model here can be saved uniformly on the server side, and can also be fed back to the client that initiates the medical data analysis request.

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

[0038] When a medical institution receives a suspected rare disease patient, how to directly share the medical condition and medical records and information provided by the rare disease patient and his family is not only inconvenient, but the data is also incomplete and there is a risk of loss due to a long period of time. Although medical data is now mostly stored electronically in various medical institutions for backup, it is difficult to directly share patient cases between different medical institutions because patient data involves personal privacy protection. Therefore, this application proposes a rare disease data sharing system based on a medical data processing system.

[0039] Figure 2 A communication flow chart of a rare disease data sharing system provided in an embodiment of the present application. Figure 2 As shown in the figure, the sharing process 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 a patient suspected or confirmed to have a rare disease is received, a data sharing request can be initiated to determine whether the patient has a rare disease or to determine further treatment plans for the rare disease.

[0042] The data sharing request at least includes the data type of the patient's case to be analyzed, that is, the data sharing request may indicate a certain image of a certain part and / or a biochemical index and / or gene sequence of a certain test, etc.

[0043] In a specific embodiment, the data sharing request may indicate that the data type of the case of the patient to be tested may include text-type physical examination data, ophthalmic examination data, family medical history survey data, genetic test list, blood test list, and may also include picture-type pathological section images of specified parts, etc.

[0044] S2. The server responds to the received data sharing request and broadcasts it to other clients to determine other clients that will participate in this data sharing.

[0045] The other clients here may 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, cities, etc.

[0046] S3. The server determines a pre-trained rare disease analysis model from the database based on the data type. The server sends 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 generated by previous training.

[0049] The rare disease analysis model here may include a feature extractor and a classifier. Here, the server distributes the feature extractor to each client to extract features from the medical data of each client.

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

[0051] For privacy protection, each client extracts features from all locally stored medical data based on a feature extractor, meaning that each patient's medical record for each visit hides personal information. The medical data here refers specifically to the patient's medical records, which include images, case forms, text 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 determines, from among all received case features, a plurality of target case features that match the patient to be analyzed.

[0054] In step S6, the server may determine multiple target case features that match the patient to be analyzed in the following manner:

[0055] First, based on the repetition value of each case feature, the corresponding first case feature set is determined. This step can preliminarily screen out patients who have repeated visits. Figure 3 As shown, the server can determine the first case feature set in the following manner:

[0056] S610. For each case feature uploaded by the client sending the data sharing request, calculate 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.

[0057] Here, the server receives multiple case features uploaded by the target client A, which can be expressed as Among them, na is the number of patient medical records in the target client, The ka-th case feature matrix included in each case feature.

[0058] The server receives multiple case features uploaded by the target client B, which can be expressed as Among them, nb is the number of patient medical records in the target client, The kb-th case feature matrix included in each case feature.

[0059] Furthermore, illustratively, and Taking the total similarity S between as an example, it can be calculated by the following formula:

[0060]

[0061] Among them, s ka，kb for The similarity value between ka，kb For ka，kbThe corresponding weight coefficient is, for The covariance between for The corresponding standard deviation, for The corresponding standard deviation, for The Euclidean norm of for The Euclidean norm of .

[0062] Exemplarily, in one embodiment of the present application, Take the similarity S calculation between 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 feature sub-matrices at the same position, randomly determine at least one pair of target values ​​at the same position. Determine whether each pair of target values ​​has the same value. Calculate the ratio between the number of target value pairs with the same value and the total number of target value pairs as the similarity.

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

[0065] It should be noted that The matrices may be different in dimension, so the matrix with smaller dimension can be used as the standard to crop the matrix with larger dimension, or fill the matrix with smaller dimension.

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

[0067] It should be noted that, since other clients include clients of different departments of the same medical institution as the target client and clients of the same or different departments of different medical institutions, different preset values ​​can be set accordingly when judging repeated occurrences. The corresponding preset value can also be set based on the length of the time interval between the patient's medical records. The shorter the time interval, the higher the preset value can be, which is conducive to improving the accuracy of repeated occurrence judgment.

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

[0069] In step S611, the step of counting the second repetition number of occurrences may be similar to the step of S610.

[0070] S612. For any case feature, calculate the repetition value based on the corresponding first repetition occurrence number and second repetition occurrence number.

[0071] The repetition value here may be the sum or product of the first repetition occurrence number and the second repetition occurrence number.

[0072] S613. Add case features with a repetition value greater than a preset value to the first case feature set.

[0073] In step S613, it can be considered that the patient corresponding to the case feature with a repetition value greater than the preset value has visited multiple hospitals and multiple departments for multiple times, and the probability of suffering from a rare disease is relatively high.

[0074] (ii) in the first case feature set, determining a plurality of target case features that match the preset case features of the patient to be analyzed.

[0075] Next, multiple target case features related to the patient to be analyzed are identified from the first case feature set. An improved algorithm based on clustering is used here.

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

[0077] All sample case features and preset case features in the first case feature set are clustered to obtain the class where the preset case features belong. The sample case features in the class are used as target case features.

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

[0079] S620, determining preset case characteristics and multiple sample case characteristics as cluster centers.

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

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

[0082] The distance here can be calculated by cosine similarity, Jaccard coefficient, etc. The sample case characteristics are assigned to the class closest to the cluster center.

[0083] S622: Determine whether each class satisfies the splitting condition.

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

[0085] For each class, the calculated mean and calculated standard deviation values ​​between the characteristics of all cases in that class were calculated.

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

[0087] If the maximum distance value is greater than the preset distance value and the calculated standard deviation value is greater than the preset standard deviation value, it is determined that the class meets the splitting condition.

[0088] When the maximum distance value is greater than the preset distance value and the calculated standard deviation value is greater than the preset standard deviation value, it means that the case characteristics in the current class are not uniform enough, and you can consider increasing the number of cluster centers. The newly added cluster center is the sample case characteristic 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 corresponding classes.

[0090] S624. If the splitting condition is not met, the cluster centers except for the preset case features are updated.

[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 a corresponding class.

[0092] After reaching the specified number of iterations, the class to which the preset case features belong 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 patient 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 sending the data sharing request inputs the target case characteristics and the preset case characteristics of the patient to be analyzed into the classifier, and obtains the multi-stage analysis results of the patient to be analyzed output by the classifier to assist in determining the final rare disease diagnosis result of the patient to be analyzed.

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

[0096] The embodiment of the present application provides a rare disease data sharing system. Based on the federated learning mechanism, the server searches based on the case features uploaded by each client, determines the case features extracted from multiple medical data of the patient to be analyzed, and then analyzes them through a rare disease analysis model to assist doctors in making disease diagnosis. While ensuring the privacy of the patient's medical data, there is no need for the patient to manually organize or provide previous case information, which provides convenience for both doctors and patients.

[0097] In one embodiment of the present application, a method for sharing rare disease data is provided, which is applicable to a server, and the method includes responding to a received data sharing request, the data sharing request includes at least the data type of the case of the patient to be analyzed, and determining a pre-trained rare disease analysis model from a database based on the data type; sending a feature extractor of the rare disease analysis model to all clients; the server determines, from all received case features, a plurality of target case features that match the patient to be analyzed; 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, which is suitable for multiple clients deployed in different medical institutions and departments. The method includes sending a data sharing request to a server, or responding to a data sharing request sent by other clients; performing feature extraction on the medical data of all patients stored locally through the received feature extractor to obtain corresponding case features; and sending all extracted case features to the server.

[0099] In an optional embodiment, the method further includes inputting the target case characteristics and preset case characteristics of the patient to be analyzed into a classifier, and obtaining multiple stage analysis results of the patient to be analyzed output by the classifier to assist in determining the final rare disease diagnosis result of the patient to be analyzed.

[0100] See also Figure 5 , Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 5 As shown in , 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 communicates with the memory 520 via the bus 530. When the machine-readable instructions are executed by the processor 510, the above-mentioned Figure 1 The steps of a method for calculating the output torque of a vehicle in the method embodiment shown are specifically implemented in accordance with the method embodiment and will not be described in detail here.

[0102] The present application also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the computer program can execute the above-mentioned Figure 1 The steps of a method for calculating the output torque of a vehicle in the method embodiment shown are specifically implemented in accordance with the method embodiment and will not be described in detail here.

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

[0104] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0105] In addition, the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

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

[0107] It should be noted that if the function is implemented in the form of a software function 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 the present application can essentially be embodied in the form of a software product, or the part that contributes to the prior art or the part of the technical solution. The computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM) random access memory (RAM), disk or optical disk, and other media that can store program codes.

[0108] In this document, relational terms such as first and second, etc. are used merely to distinguish one entity or operation from another entity or operation, but do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0109] The above description is only an embodiment of the present application and is not intended to limit the protection scope of the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A rare disease data sharing system, characterized in that: The sharing system includes a server and multiple clients deployed in different medical institutions and departments. The server responds to the received data sharing request, wherein the data sharing request includes at least the data type of the patient's case to be analyzed, and determines a pre-trained rare disease analysis model from the database based on the data type; The server sends the feature extractor of the rare disease analysis model to all clients; Each client extracts features from all the patients’ medical data stored locally through the received feature extractor to obtain the corresponding case features; Each client sends all extracted case features to the server; The server determines, from among all received case features, a plurality of target case features that match the patient to be analyzed; 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; The client that sends the data sharing request inputs the target case characteristics and the preset case characteristics of the patient to be analyzed into the classifier, and obtains the multi-stage analysis results of the patient to be analyzed output by the classifier to assist in determining the final rare disease diagnosis result of the patient to be analyzed.

2. The system according to claim 1, characterized in that The server determines multiple target case characteristics matching the patient to be analyzed in the following manner: Based on the repetition value of each case feature, determining a corresponding first case feature set; In the first case feature set, a plurality of target case features matching the preset case features of the patient to be analyzed are determined.

3. The system according to claim 2, characterized in that The server determines the first case feature set in the following way: For each case feature uploaded by the client sending the data sharing request, calculate 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 sending the data sharing request, calculate the similarity between the case feature and other case features to determine the second repetition number of each case feature on the client sending the data sharing request; For any case feature, the repetition value is calculated based on the corresponding first repetition occurrence number and second repetition occurrence number; The case features with a repetition value greater than the preset value are added to the first case feature set.

4. The system according to claim 3, characterized in that Case features include multiple case feature matrices. The server calculates the similarity between any two case features in the following way: Divide each case feature matrix into multiple sub-matrices; For the submatrices at the same position of any two case features, at least one pair of target values ​​at the same position is randomly determined; Determine whether each pair of target values ​​has the same value; The ratio between the number of target value pairs with the same numerical value and the total number of target value pairs is calculated as the similarity.

5. The system according to claim 2, characterized in that The server determines multiple target case characteristics that match the preset case characteristics of the patient to be analyzed in the following way: Clustering all sample case features and preset case features in the first case feature set to obtain the class to which the preset case features belong; The sample case characteristics in the class are used as target case characteristics.

6. The system according to claim 5, characterized in that The server clusters all sample case features and preset case features in the first case feature set in the following way: Determine the preset case characteristics and multiple sample case characteristics as cluster centers; Based on the distance between each sample case feature and the cluster center, the sample case feature is assigned to each cluster center to generate the corresponding class; Determine whether each class meets the splitting conditions; If the splitting condition is met, the cluster center is added, and the step of assigning sample case characteristics to each cluster center to generate the corresponding class is returned; If the splitting condition is not met, the cluster centers except for the preset case characteristics are updated; Determine whether the specified number of iterations has been reached. If not, return to the step of assigning sample case characteristics to each cluster center to generate the corresponding class.

7. The system according to claim 6, characterized in that The server determines whether each category meets the splitting conditions in the following ways: For each class, the calculated mean and calculated standard deviation values ​​between the characteristics of all cases in that class were calculated; Calculate the distance value between the calculated mean and each case feature in the class, and determine whether the maximum distance value is greater than a preset distance value; and determining whether the calculated standard deviation value is greater than a preset standard deviation value; If the maximum distance value is greater than the preset distance value and the calculated standard deviation value is greater than the preset standard deviation value, it is determined that the class meets the splitting condition.

8. A method for sharing rare disease data, characterized in that: Applicable to the server, the method includes: In response to the received data sharing request, the data sharing request includes at least the data type of the patient's case to be analyzed, and determining a pre-trained rare disease analysis model from a database based on the data type; Send the feature extractor of the rare disease analysis model to all clients; The server determines, from among all received case features, a plurality of target case features that match the patient to be analyzed; The target case characteristics and the classifier of the rare disease analysis model are fed back to the client that sent the data sharing request.

9. A method for sharing rare disease data, characterized in that: Applicable to multiple clients deployed in different medical institutions and departments, the method includes: Send data sharing requests to the server, or respond to data sharing requests sent by other customers; Perform feature extraction on the medical data of all patients stored locally through the received feature extractor to obtain corresponding case features; Send all extracted case features to the server.

10. The method according to claim 9, characterized in that It also includes inputting the target case characteristics and the preset case characteristics of the patient to be analyzed into a classifier, and obtaining multiple stage analysis results of the patient to be analyzed output by the classifier to assist in determining the final rare disease diagnosis result of the patient to be analyzed.

Images