Blockchain and federated learning-based medical community data security sharing method and system

Abstract

The present application proposes a medical community data security sharing method and system based on blockchain and federated learning, which comprises: obtaining the events found by each medical institution according to the task authorization boundary. According to the task identification and the patient main index, the task internal association index of each event is obtained, and the events corresponding to the same task internal association index are combined to form a task internal course event chain. The event admission value of each node in the task internal course event chain is calculated, and if the event admission value is greater than or equal to the event admission threshold, the corresponding node is selected into the task controlled course event chain. A local training list is generated for each controlled chain node in the task controlled course event chain, the local model parameters obtained by each medical institution based on the local training list are obtained, the aggregation weight of each medical institution is calculated, and the federated aggregation is carried out according to the aggregation weight and the local model parameters to obtain the federated model, which realizes the security sharing of the medical community data and improves the prediction accuracy of the aggregated model.

Description

Technical Field

[0001] This invention belongs to the field of medical data processing, and in particular relates to a method and system for secure data sharing in medical consortia based on blockchain and federated learning. Background Technology

[0002] With the advancement of county-level medical consortia, urban medical groups, and regional medical collaboration platforms, the patient treatment process is increasingly characterized by multi-institutional participation, cross-stage continuity, and long-term management at the grassroots level. This is particularly evident in the management of chronic diseases such as diabetes and hypertension, as well as in the prediction of complication risks. Patient diagnosis, testing, medication, and follow-up information are typically stored separately in county-level hospitals, primary healthcare centers, community health service centers, and their internal operational systems. Data held by a single institution often only reflects a partial stage of the patient's disease progression. Training models based solely on local data from a single medical institution can easily result in training samples that only reflect localized treatment behaviors, failing to express the continuous changes in the patient's journey from diagnosis, testing, medication to follow-up. Federated learning allows each medical institution to retain its original data locally, uploading only model parameters for aggregation. This reduces the risk of data leakage from centralized aggregation of original data. However, different events occurring in different institutions for the same patient cannot be naturally organized into a continuous disease progression object within the current task, leading to low prediction accuracy in the aggregated model. Therefore, improving the prediction accuracy of the aggregated model while ensuring secure data sharing within the medical consortium has become a pressing technical challenge. Summary of the Invention

[0003] The purpose of this invention is to provide a method and system for secure data sharing within a medical consortium based on blockchain and federated learning, which can improve the prediction accuracy of the aggregation model while achieving secure data sharing within the medical consortium.

[0004] To achieve the above objectives, a first aspect of the present invention provides a method for secure data sharing within a medical consortium based on blockchain and federated learning, the method comprising: The task authorization boundary is sent to the medical institutions corresponding to the allowed participating institutions, and the standard disease course events found by each medical institution according to the task authorization boundary are obtained; wherein, the standard disease course events correspond to the patient master index, and the task authorization boundary includes the task identifier and the allowed participating institutions; Message authentication is performed based on the task identifier and the patient master index to obtain the intra-task association index corresponding to each standard disease course event, and the standard disease course events corresponding to the same intra-task association index are formed into an intra-task disease course event chain. Obtain the number of event types and cross-institutional consecutive markers of the disease course event chain within the task, and calculate the disease course coverage value of each disease course event chain within the task based on the number of event types, the cross-institutional consecutive markers, a preset configuration coefficient, and a preset total number of event types; Obtain the authorization matching value and node continuity value of each node in the disease course event chain within the task. Calculate the event admission value of each node based on the authorization matching value, the disease course coverage value, the node continuity value, and the preset disease course coverage weight. If the event admission value is greater than or equal to the preset event admission threshold, the corresponding node is selected into the task-controlled disease course event chain. A local training list is generated for each controlled chain node in the controlled disease event chain of the task. Local model parameters of each medical institution are obtained based on the local training list. The aggregation weight of each medical institution is calculated according to the event admission value, the disease coverage value and the preset disease coverage enhancement coefficient corresponding to all controlled chain nodes of each medical institution. Federated aggregation is performed according to the aggregation weight and the local model parameters to obtain the federated model.

[0005] Furthermore, the task authorization boundary also includes output granularity constraints. After performing federated aggregation based on the aggregation weights and the local model parameters to obtain the federated model, the method further includes: If the output granularity constraint indicates publishing a model service, then publish the model version identifier, applicable task identifier, scope of callable organizations, and service interface identifier of the federated model. If the output granularity constraint indicates that the risk stratification results are to be published, then the model output is converted into a low-risk, medium-risk, or high-risk level according to the risk threshold configured in the task, and the risk level results are published to the authorized agency. If the output granularity constraint indicates that statistical results are to be published, then the summary results within the scope of the task are published. Furthermore, obtaining the number of event types and cross-agency continuous markers of the disease event chain within the task includes: The event types within the disease process event chain of the task are statistically analyzed to obtain the number of event types. Determine whether there are adjacent nodes with different institutional identifiers in the disease event chain within the task. If the determination result is yes, the cross-institutional consecutive marker is one; if the determination result is no, the cross-institutional consecutive marker is zero.

[0006] Further, the step of calculating the disease coverage value of each disease event chain within a task based on the number of event types, the cross-agency continuous markers, the preset configuration coefficient, and the preset total number of event types includes: Multiply the configuration coefficient by the cross-organizational continuous marker, and then add it to the number of event types to obtain the first data; The disease course coverage value is obtained by dividing the first data by the sum of the total number of event types and the configuration coefficient.

[0007] Further, obtaining the authorization matching value and node continuity value of each node in the disease event chain within the task includes: Determine whether the task identifier of the node is consistent with the task identifier of the task authorization boundary, whether the event type of the node is consistent with the allowed event type of the task authorization boundary, whether the organization identifier of the node belongs to the allowed participating organization of the task authorization boundary, and whether the event time of the node falls within the allowed disease course time range of the task authorization boundary. If the determination results are all yes, the authorization matching value is one; otherwise, the authorization matching value is zero. If the authorization matching value of the previous node and the next node of the current node are both one, then the node continuity value of the current node is one. If the authorization matching value of only one node of the previous node or the next node of the current node is one, then the node continuity value of the current node is half. If the authorization matching value of the previous node and the next node of the current node is zero, then the node continuity value of the current node is zero.

[0008] Further, the step of calculating the event admission value for each node based on the authorized matching value, the disease course coverage value, the node continuity value, and the preset disease course coverage weight includes: Multiply the disease course coverage weight by the disease course coverage value to obtain the second data; subtract the preset number from the disease course coverage weight, and then multiply by the node continuity value to obtain the third data. The second data is added to the third data, and then multiplied by the authorization matching value to obtain the event admission value.

[0009] Further, the step of calculating the aggregate weight of each medical institution based on the event admission value, the disease coverage value, and the preset disease coverage enhancement coefficient corresponding to all controlled chain nodes of each medical institution includes: Multiply the disease course coverage enhancement coefficient by the disease course coverage value, and then add it to a preset number to obtain the fourth data. Multiply the fourth data by the event admission value to obtain the node contribution of the controlled chain node. The controlled event contribution is obtained by summing the node contributions corresponding to all controlled chain nodes of the medical institution, and then by dividing the controlled event contribution by the sum of all controlled event contributions to obtain the aggregate weight.

[0010] A second aspect of the present invention provides a secure data sharing system for medical consortia based on blockchain and federated learning, the system comprising: The acquisition unit is used to send the task authorization boundary to the medical institutions corresponding to the allowed participating institutions, and to acquire the standard disease course events found by each medical institution according to the task authorization boundary; wherein, the standard disease course events correspond to a patient master index, and the task authorization boundary includes a task identifier and the allowed participating institutions; An authentication unit is used to perform message authentication based on the task identifier and the patient master index, obtain the intra-task association index corresponding to each standard disease course event, and form an intra-task disease course event chain by combining the standard disease course events corresponding to the same intra-task association index. The first calculation unit is used to obtain the number of event types and cross-institutional continuous markers of the disease course event chain within the task, and to calculate the disease course coverage value of each disease course event chain within the task based on the number of event types, the cross-institutional continuous markers, a preset configuration coefficient, and a preset total number of event types. The second calculation unit is used to obtain the authorization matching value and node continuity value of each node in the disease course event chain within the task, and calculate the event admission value of each node based on the authorization matching value, the disease course coverage value, the node continuity value and the preset disease course coverage weight. If the event admission value is greater than or equal to the preset event admission threshold, the corresponding node is selected into the task-controlled disease course event chain. The aggregation unit is used to generate a local training list for each controlled chain node in the task-controlled disease course event chain, obtain the local model parameters of each medical institution based on the local training list, calculate the aggregation weight of each medical institution according to the event admission value, the disease course coverage value and the preset disease course coverage enhancement coefficient corresponding to all controlled chain nodes of each medical institution, and perform federated aggregation according to the aggregation weight and the local model parameters to obtain the federated model.

[0011] In a third aspect of the invention, an electronic device is provided, the electronic device including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the method described in the first aspect above.

[0012] In a fourth aspect of the invention, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect.

[0013] The beneficial technical effects of the present invention are at least as follows: To address the aforementioned issues, this invention provides a method and system for secure data sharing within a medical consortium based on blockchain and federated learning. Its core lies in first using the task authorization boundaries fixed on the consortium blockchain as the basis for local event generation by each institution. This allows medical institutions to generate standard disease progression events only for the diseases, institutional scope, event types, and disease duration ranges permitted by the current task. A structured event set, usable for subsequent organization, is formed through task-internal association indexes, event times, event types, affiliated institution identifiers, and event summaries. Subsequently, the standard disease progression events are aggregated according to task identifiers and task-internal association indexes, and a task-internal disease progression event chain is generated by combining event times, event type order, and event identifiers. Simultaneously, a disease progression coverage value, reflecting the coverage of diagnosis, testing, medication, follow-up, and cross-institutional continuity, is calculated, enabling the local events scattered across different institutions to be shared securely. Within the current task scope, a continuous disease course object is constructed. Based on this, the disease course event chain within the task is selected at the event level according to the on-chain task authorization boundary. The authorization matching result of the node, the disease course coverage value, and the node continuity relationship are jointly transformed into the event admission value to obtain the task-controlled disease course event chain set, thereby implementing the on-chain authorization boundary at the level of trainable chain nodes. Finally, each medical institution only calls local records to complete federated learning training based on the nodes belonging to its own institution in the task-controlled disease course event chain. The aggregator calculates the institution's contribution weight based on the event admission value and the disease course coverage value and generates a federated model. Then, the model service, risk stratification results, or statistical results are released according to the on-chain output granularity constraints. The original chain summary, controlled chain summary, node event summary, participating institutions, aggregation weight, model version, and shared result identifier are written into the consortium chain audit record. Through the above design, this invention transforms blockchain from a simple authorization and evidence storage tool into a control basis for the training scope and result publication boundaries of federated learning. It transforms federated learning from coarse-grained aggregation of local datasets by institution into training and aggregation around a task-controlled disease event chain. This enables the continuous disease value formed across institutions within the medical consortium to participate in model training without the original data leaving the institution. Furthermore, it establishes a closed loop between training objects, aggregation basis, shared results, and audit records under the same task identifier, thereby improving the prediction accuracy of the aggregation model while ensuring secure data sharing within the medical consortium. Attached Figure Description

[0014] The present invention will be further described with reference to the accompanying drawings, but the embodiments in the drawings do not constitute any limitation on the present invention. For those skilled in the art, other drawings can be obtained based on the following drawings without creative effort.

[0015] Figure 1 This is a flowchart of a method for secure data sharing in a medical consortium based on blockchain and federated learning, provided in an embodiment of this application.

[0016] Figure 2This is a schematic diagram of the structure of a medical consortium data security sharing system based on blockchain and federated learning provided in the embodiments of this application. Detailed Implementation

[0017] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0018] Please refer to Figure 1 , Figure 1 This is a flowchart of a method for secure data sharing within a medical consortium based on blockchain and federated learning, provided in an embodiment of this application. Figure 1 The method may include, but is not limited to, steps S101 to S105.

[0019] Step S101: Send the task authorization boundary to the medical institutions corresponding to the allowed participating institutions, and obtain the standard disease course events found by each medical institution according to the task authorization boundary; wherein, the standard disease course events correspond to the patient master index, and the task authorization boundary includes the task identifier and the allowed participating institutions; Step S102: Message authentication is performed based on the task identifier and the patient master index to obtain the intra-task association index corresponding to each standard disease course event, and the standard disease course events corresponding to the same intra-task association index are formed into an intra-task disease course event chain. Step S103: Obtain the number of event types and cross-institutional continuous markers of the disease event chain within the task; calculate the disease coverage value of each disease event chain within the task based on the number of event types, cross-institutional continuous markers, preset configuration coefficients, and preset total number of event types. Step S104: Obtain the authorization matching value and node continuity value of each node in the disease course event chain within the task. Calculate the event admission value of each node based on the authorization matching value, disease course coverage value, node continuity value, and preset disease course coverage weight. If the event admission value is greater than or equal to the preset event admission threshold, the corresponding node is selected into the task-controlled disease course event chain. Step S105: Generate a local training list for each controlled chain node in the task-controlled disease course event chain, obtain the local model parameters of each medical institution based on the local training list, calculate the aggregation weight of each medical institution according to the event admission value, disease course coverage value and preset disease course coverage enhancement coefficient corresponding to all controlled chain nodes of each medical institution, and perform federated aggregation according to the aggregation weight and local model parameters to obtain the federated model.

[0020] In steps S101 to S102 of some embodiments, when performing this federated learning task, the member institutions of the medical consortium first read the already fixed task authorization boundary from the medical consortium blockchain. ,in This serves as the task identifier for this mission, and is written into the consortium blockchain by the medical consortium management or authorized management system before the mission starts. This includes the target disease, permitted participating institutions, permitted event types, permitted disease duration range, and output granularity constraints. Each medical institution corresponding to a permitted participating institution is determined according to... The target disease, allowed event types, and allowed disease duration range are used to form local event generation conditions for the current task within the institution's internal system, thereby finding corresponding standard disease duration events. For example, when the target disease is diabetes, the local system establishes search conditions based on diabetes-related diagnosis, testing, medication, and follow-up records. When allowed event types are limited to diagnosis events, testing events, medication events, and follow-up events, the system reads the corresponding internal data tables, interfaces, or message topics for these four types of events. Diagnostic records come from the electronic medical record system or outpatient and inpatient diagnostic forms; testing records come from the laboratory information system; medication records come from the prescription system or medical order system; and follow-up records come from the primary care chronic disease follow-up system or family doctor contract follow-up system. During project implementation, medical institutions can read candidate records through read-only views of the internal database, internal interface services, front-end machine interfaces, or message buses. The reading conditions are determined by... The target disease, institutional scope, event type, and time frame are jointly determined.

[0021] The authorization records are stored on the blockchain as structured records, including at least the task identifier, authorization record version, disease coding range, set of institution identifiers, set of event types, start and end times, output granularity, model task type, task validity period, and authorization record summary. Each medical institution reads... First, the authorization record version, on-chain signature or endorsement status, and task validity period are verified. If the local institution identifier is not within the set of allowed participating institutions, or if the version of the local event type mapping table is inconsistent with the task requirements, the local system will not generate a standard disease event. This process ensures that local event generation does not rely on manual ad-hoc judgment, but is jointly limited by the on-chain fixed task authorization boundaries and the local mapping table.

[0022] Taking the task of predicting the risk of diabetes complications as an example, County People's Hospital A reads the relevant test item categories and report times from the laboratory information system and converts them into test events; Township Health Center B reads the follow-up categories, follow-up occurrence times, and follow-up conclusion categories related to diabetes management from the chronic disease follow-up system and converts them into follow-up events; Community Health Service Center C reads the medication categories and prescription times that match the task's disease type and time range from the prescription system and converts them into medication events. All the above conversions are completed locally at the data holding institution, and the conversion results adopt a unified standard disease course event structure. Each standard disease course event includes an event identifier, task-related index, event type, event time, affiliated institution identifier, event summary, and task identifier. The event identifier is generated by the local system within the current task; the event type is taken from... Allowed event types; event time is taken from the diagnosis confirmation time, test report time, prescription generation time, or follow-up completion time in the local system; the affiliated institution identifier is taken from the registration information of the medical consortium member institutions; the task identifier is taken from... The event summary is generated by the local system based on the local record number, event type, event time, affiliated institution identifier, and task identifier. It is used to prove the correspondence between the event and the local record in subsequent on-chain audits. Standard medical events are written with structured results such as task-related indexes, event category, time, institution, summary, and task identifier. The original medical record text, complete test reports, complete prescription content, and original follow-up Q&A continue to be stored by the local business system.

[0023] Different medical institutions often have coding differences in diagnostic names, laboratory tests, drug lists, and follow-up templates. Therefore, the local system performs local mapping before generating standard disease progress events. Diagnostic events are mapped from local diagnostic names or local diagnostic codes to... The system allows for the following target disease categories: Laboratory events are mapped from local laboratory item codes to pre-configured laboratory item categories within the medical consortium; medication events are mapped from the local drug catalog to pre-configured drug categories within the medical consortium; and follow-up events are mapped from the follow-up type in the primary care follow-up template to the follow-up category allowed for the current task. For example, different institutions may record names such as "Type 2 Diabetes," "Adult-Onset Diabetes," and "Non-Insulin Dependent Diabetes," etc. The local system maps these names uniformly to the diabetes diagnosis event category for the current task based on the medical consortium's disease mapping table. For prescription records, the local drug name is used to determine its drug category, and the medication event category is written into the standard disease course event. For follow-up records, structured items such as "blood glucose control status," "medication adherence category," and "complication indication" in the follow-up template are used to form the follow-up event category and follow-up conclusion category. This mapping enables events generated by different institutions to participate in the construction of the disease course event chain in subsequent steps according to a unified event type.

[0024] The intra-task association index is used to subsequently organize diagnostic events, testing events, medication events, and follow-up events for the same patient within the current task into a single intra-task disease progression event chain. This index is based on a keyed hash message authentication code algorithm, a classic cryptographic message authentication algorithm used to generate authentication results for input messages with the participation of a key. Its basic structure can be represented as follows: ; in, Indicates the use of a key For input messages The generated authentication result; This indicates a secure hash algorithm, implemented by the local system or the medical consortium identity index gateway calling a standard cryptographic library; The key materials used for authentication are generated by the authorization system. This represents the message to be authenticated, which corresponds to the input content within the task in this invention, i.e., in the following formula. ; This indicates that the outer layer has a fixed padding value, which is predetermined by the message authentication algorithm specification. This indicates that the inner fixed padding value is predetermined by the message authentication algorithm specification; This indicates a bitwise XOR operation; This indicates the concatenation of character or byte sequences. All the above operations are performed on character or byte sequences, and the input and output data types are consistent.

[0025] Key materials and subsequent task key materials None of these are written to the consortium blockchain, nor are they transmitted with the federated learning parameters; their generation, distribution, rotation, and destruction are executed by the medical consortium's authorization system or key management service, and are bound to the task identifier, institution identifier, and validity period. Fixed fill value. and Employs byte padding values ​​and secure hash algorithms as specified in the message authentication algorithm specification. The algorithm can be uniformly configured by the medical consortium to meet local cryptographic compliance requirements.

[0026] In this invention, the current task identifier is introduced into the message to be authenticated. Message authentication is performed based on the task identifier and the patient master index. The authentication result is then truncated to form an intra-task association index used within the current task, as shown in the following formula: ; in, This indicates an associated index within the task, which is written to standard disease process events by the local system. This indicates that a character segment of a preset length will be extracted from the authentication result. The extraction length is determined by the authorization configuration before the task starts. Indicates the use of task key materials The keyed hash message authentication computation is performed using a standard cryptographic library. This indicates the key material corresponding to the current task, which is determined by the authorization system based on the task identifier. Generate or allocate; This represents the task-input value after the local patient master index has been processed by the medical consortium identity index gateway. The local patient master index is used to distinguish different patients within the medical institution. The task-input value is an intermediate index value generated by the identity index gateway within the scope of the current task. This avoids directly using the local patient master index to participate in on-chain or cross-institutional event associations, while ensuring that the same patient within the same task can obtain a consistent association basis. The task identifier representing the current federated learning task comes from the on-chain task authorization boundary; Indicates will and Perform character or byte sequence concatenation. This formula is based on the aforementioned keyed hash message authentication algorithm, and incorporates the task identifier. As part of the message, an interception step is added to obtain the intra-task association index. The same intra-task association index is obtained for the same patient in the same task. The same intra-task association index can associate the standard course events of the same patient in the same task with the same course event chain in the same task.

[0027] Generated by the identity index gateway in the privacy computing front-end environment of this institution or medical consortium, it can be obtained from the patient master index, in-institutional patient number, and task authorization scope through de-identification mapping, but the patient's name, ID number, mobile phone number, or complete in-hospital patient number is not written in the standard medical event. (Truncation length) Determined by the task configuration, the preferred length is not less than the length required to meet the conflict probability under the current task size; if the collaborative indexing service finds the same [item] within the same task... If there are clearly inconsistent event summary sources or identity index conflict markers, they will not be directly merged into the same task's disease course event chain, but will instead enter the conflict verification queue. This process ensures that the task-related association index is used for chain organization, and does not become a plaintext identifier that can be used to infer patient identity.

[0028] In actual deployment, the medical consortium authorization system serves as the task... distribute The identity index gateway converts the local patient master index into in-task input values. The local system will and After concatenation, the standard cryptographic library is called to calculate the authentication result, and then... Extract the preceding character fragment as For example, task identifiers. Configured as "Diabetes Risk Task 2026 No. 1", length extracted Configured with 24 hexadecimal characters, when the same patient generates a diagnosis event at County A People's Hospital and a follow-up event at Township B Health Center, the identity index gateway generates the same [characters] under this task. Both institutions received the same Subsequently, these two events can be arranged into the same intra-task disease course event chain. When the same patient enters another hypertension risk task, the task identifier and task key change with the task, and the generated intra-task association index is used for event organization within that hypertension task. This calculation process confines patient association needs to the specific federated learning task and provides stable association keys for the next step of disease course event chain generation.

[0029] After generating standard medical process events, each medical institution writes these events to the local event cache of the current task and submits the event identifier, intra-task association index, event type, event time, affiliated institution identifier, event summary, and task identifier to the medical consortium collaborative index service or the consortium blockchain task recording component. Subsequent steps use these fields to generate intra-task medical process event chains: the intra-task association index identifies the chain of events within the same task, the event time determines the order of events on the chain, the event type identifies the category of the medical process node, the affiliated institution identifier locates the data holding institution corresponding to the event, the event summary is used for training scope auditing, and the task identifier limits the task to which the event belongs. This step outputs a set of standard medical process events. , It consists of multiple standard course events for all patients within the current task scope, that is, each medical institution based on All standard disease process events found are used as direct input for the next step of generating a set of disease process event chains within the task. Through this step, the task authorization boundary on the chain enters the local event generation process, and the diagnosis, test, medication, and follow-up records within the medical consortium are converted into unified and task-constrained standard disease process events, providing organized and auditable training candidates for subsequent secure sharing based on federated learning.

[0030] The event summary is generated locally based on local record references, event type, event time, affiliated institution identifier, task identifier, and the institution's summary salt value. The summary salt value is stored locally within the institution or in the key management service and is not written to the on-chain public record. Event fields submitted to the collaborative index service or consortium blockchain side components do not contain the original medical record text, complete test values, prescription details, or follow-up access responses. When training is required, the affiliated institution locates the original record based on the event identifier and local reference relationship and generates training features locally. This on-chain / off-chain boundary allows standard medical event progressions to be organized and audited across institutions without causing centralized leakage of original medical data.

[0031] Furthermore, the standard course event set The discrete standard pathological events that have already been formed are a set of in-task pathological event chains. .gather Each standard disease progression event in the system includes an event identifier, a task-based association index, an event type, an event time, an affiliated institution identifier, an event summary, and a task identifier. These fields serve specific purposes: the task identifier confirms that the event belongs to the same federated learning task; the task-based association index groups events belonging to the same candidate patient's disease progression within the current task into the same group; the event time determines the chronological order of the event within the disease progression; the event type identifies disease progression stages such as diagnosis, testing, medication, and follow-up; the affiliated institution identifier retains the data holding institution corresponding to the event; the event summary forms a chain summary for subsequent auditing; and the event identifier determines a stable arrangement within the same time and event type. In a medical consortium scenario, a patient's diagnostic event may originate from a county-level hospital, a testing event from a county-level testing center or county hospital, a medication event from a community health service center, and a follow-up event from a primary healthcare facility. These standardized events are organized into a chain according to the patient's disease progression relationship within the current task, enabling subsequent steps to perform event-level selection and federated learning control at the disease progression chain node level.

[0032] Medical consortium collaborative indexing service or consortium blockchain side task record component receiving set Then, first follow the task identifier. Event aggregation ensures that events corresponding to the same federated learning task are placed in the same processing domain. Subsequently, in the task identifier... Within the scope of the task-related index Grouping events with the same characteristics Standard disease course events are grouped into the same candidate disease course group, i.e., the unordered event group of the in-task disease course event chain. This grouping directly uses the in-task association index, which can aggregate diagnostic events, laboratory events, medication events, and follow-up events from different institutions for the same patient under the same task into the same candidate disease course group. For example, in the diabetes complication risk prediction task, diagnostic events generated by County People's Hospital A, laboratory events generated by the county hospital's laboratory system, medication events generated by Community Health Service Center C, and follow-up events generated by Township Health Center B, if they have the same in-task association index, can be grouped into the same candidate disease course group. If they are repeated, they will be grouped into the same candidate disease course group. The event summary is used in the grouping stage to identify repeated standard disease course events; for multiple records corresponding to the same task identifier, the same task association index, and the same event summary, the system retains the earliest generated event identifier as the chain node, and registers the remaining repeated records as the source reference of the chain node, thereby ensuring that each node in the subsequent chain has a unique reference relationship.

[0033] Within each candidate disease course group, the system deterministically sorts standard disease course events. This sorting rule is initially derived from the lexicographical ordering concept in discrete mathematics, which involves setting multiple sorting keys for the same group of objects and comparing them sequentially according to the priority of these keys, ensuring a consistent sequence for the same batch of objects across different execution environments. This invention extends this concept to the scenario of constructing a medical consortium disease course chain, using event time as the first sorting key to express the order of disease course occurrence; event type order as the second sorting key to handle situations where multiple disease course events exist at the same time; and event identifier as the third sorting key to handle situations where multiple events exist at the same time and under the same event type. The event type order is determined by the current task configuration. For example, in a chronic disease risk prediction task, diagnostic events are used to confirm the managed object, laboratory events are used to reflect phased indicators, medication events are used to express treatment interventions, and follow-up events are used to express primary care management results. Therefore, at the same time, events can be arranged as diagnostic events, laboratory events, medication events, and follow-up events. In medication safety tasks, the medical consortium can place medication events at the forefront of the task configuration to reflect the task's focus on medication behavior. The sorting rules are expressed as follows: ; in, Indicates the association index within the task. The corresponding standard disease course events form the task-specific disease course event chain; Indicates the sorted order of the first... A standard course event, which comes from a set ; Represents a chain The number of standard course events included is determined by the same task identifier. and related indexes within the same task The number of events was obtained; Indicates an event The event time is derived from the event time field written to the standard disease course event; Indicates an event The event type order value is obtained by the order in which diagnostic events, test events, medication events, and follow-up events are set in the current task configuration; Indicates an event Event identifier; This formula represents the sequential relationship obtained by comparing events in order of time, type, and identifier. The comparison objects in this formula are time values, sequence values, or identifier values, and the sorted result is an ordered sequence of events, conforming to the engineering implementation logic of chain node arrangement.

[0034] When generating chain nodes according to the above rules, the system retains a standard disease course event field for each node and supplements the node position and adjacent node relationships in the chain structure. The node position is determined by the sorting result; the first node serves as the starting node for candidate disease courses within the current task, and the last node serves as the ending node within the current task scope. Adjacent node relationships are formed by two adjacent events after sorting, used to represent the continuous changes in the patient's disease course across different treatment stages and institutions. Taking the diabetes complication risk prediction task as an example, the associated index within a certain task... There are four events: a diagnosis event at County A People's Hospital on January 3, 2026; a laboratory test event at County A People's Hospital on January 5, 2026; a medication administration event at Community Health Service Center C on January 5, 2026; and a follow-up event at Township Health Center B on March 10, 2026. The system first places the diagnosis event of January 3 at the head of the chain. If both a laboratory test and a medication administration event exist on January 5, the system prioritizes the laboratory test event over the medication administration event in the current task, placing the laboratory test event before the medication administration event. The follow-up event of March 10 is placed at the tail of the chain. This ultimately forms a chain structure of "diagnosis event - laboratory test event - medication administration event - follow-up event," with each node retaining its affiliated institution identifier, enabling subsequent steps to identify the continuous medical relationship between the county-level hospital, community health service center, and primary health center involved in the chain.

[0035] In step S103 of some embodiments, in order to make the generated intra-task disease event chain more closely fit the medical consortium federated learning task, the system calculates a disease coverage value for each chain. The initial source of this calculation is the concept of set coverage in combinatorial optimization, whose basic form is "the number of covered target elements divided by the total number of target elements," used to evaluate the degree of coverage of a candidate set over the target set. In this invention, the target set is set as four core disease course events: diagnostic events, testing events, medication events, and follow-up events, and the candidate set is a chain. The actual set of event types that occur in the data. Since the value of data sharing within a medical consortium comes not only from event type coverage but also from the continuous collaboration between different institutions, cross-institutional continuous terms are introduced on top of the basic coverage. And through configuration coefficients Control the impact of this item on the coverage value. To keep the calculation results within a stable range, the denominator is added synchronously. As a normalization term, the calculation method is to multiply the configuration coefficient by the cross-institutional continuous label, and then add it to the number of event types to obtain the first data; the first data is divided by the sum of the total number of event types and the configuration coefficient to obtain the disease coverage value. As shown in the following formula: ; in, Indicates the disease process event chain within the task. The disease course coverage value is written into the disease course event chain record within the task; Represents a chain The set of event types that have already appeared in the chain is obtained by counting the event type field of the chain node. The event types are limited to diagnostic events, test events, medication events, and follow-up events. Represents a set The number of different event types in the data; Indicates a continuous marker across institutions, when the chain... If at least one set of adjacent nodes have different organization identifiers, then the consecutive cross-organization marker is set to one; otherwise, it is set to zero. This value is obtained by comparing the organization identifiers of the chain nodes. The configuration coefficient for cross-institutional continuous terms is set by the medical consortium in the task configuration; the four in the denominator represents the total number of event types, indicating the total number of the four core disease course events defined in this invention. This formula is based on the coverage rate of the basic set. Based on this deduction, cross-institutional continuous labeling is considered a structural compensation item unique to the medical consortium scenario, and is further developed through... For molecules Synchronous normalization is performed so that the coverage value changes monotonically with event type coverage and cross-agency continuity.

[0036] The value range is from zero to four. For binary labeling, This is a dimensionless, non-negative configuration coefficient, preferably limited to between zero and two, and written into the parameter table along with the task configuration. When the value is zero, the disease course coverage value degenerates into the coverage ratio of the four core events; when When the value is greater than zero, cross-institutional continuity compensates for the coverage value but does not cause it to... If a task only allows two or three event types, the medical consortium can synchronize the total number of event types in the task configuration to the number of core events allowed for that task, and write this number into the task configuration to avoid inconsistencies between the denominator and the task authorization boundary.

[0037] In conjunction with actual deployment, if a chain in a diabetes risk task... The nodes include four types: diagnostic events, laboratory events, medication events, and follow-up events. Furthermore, if there are institutional changes between adjacent nodes, such as from County People's Hospital A to Community Health Service Center C, or from Community Health Service Center C to Township Health Center B, then... Four, One. If the current task is configured... If it is one, then The other chain contains only diagnostic and testing events, and both nodes originate from the same county hospital. Two, Zero, under the same configuration For example, if the third chain includes diagnostic events, testing events, and follow-up events, and the diagnostic events originate from the county hospital and the follow-up events originate from the primary healthcare center, then... Three, As one, The above calculations show that the disease coverage value can distinguish between complete cross-institutional disease event chains, single-institutional partial disease event chains, and disease event chains that are partially covered but have a collaborative relationship within a medical consortium. This allows the next step to process event-level selection in conjunction with the completeness of the chain structure.

[0038] After each task-based disease event chain is generated, the system forms a chain digest based on the order of event digests of the nodes in the chain. The chain digest is obtained by concatenating a sorted sequence of event digests and performing a secure hash, and then writing it into the chain record. The event digests have already been generated by the local system in the above steps, and the chain digest uses an ordered sequence of event digests. For a single-node chain, the chain digest is calculated from the event digest of that node; for a multi-node chain, the chain digest is calculated by concatenating multiple node event digests according to the chain node order. The chain digest is used to identify the node composition and node order of the chain under the current task. When selecting chain nodes at the event level in subsequent steps, the chain digest and node event digests can be referenced to prove that the selected node comes from the set of disease event chains within the task. The chain digest and the disease coverage value together constitute the chain-level attributes, where the chain digest is used for structural fingerprint recording, and the disease coverage value is used to express the degree of coverage of the chain structure to the current medical consortium task.

[0039] In engineering implementation, this step can be executed by the medical consortium collaborative indexing service, or by the task record component on the consortium blockchain side in collaboration with the off-chain indexing service. The collaborative indexing service receives standard disease course event fields from various medical institutions, groups them according to task identifiers and intra-task association indexes, and performs duplicate event identification, deterministic sorting, chain node generation, disease course coverage value calculation, and chain summary generation. The chain node record stores the event identifier, intra-task association index, event type, event time, affiliated institution identifier, event summary, and task identifier; the chain record stores the intra-task association index, chain node order, disease course coverage value, and chain summary. For subsequent standard disease course events arriving in the same task, the system locates the existing chain according to the event's task identifier and intra-task association index, inserts the event into the position that conforms to the sorting rules, and updates the chain summary and disease course coverage value. After the task execution window closes, the system solidifies the set of intra-task disease course event chains for the task, which can be directly read by the next step.

[0040] This step outputs a set of disease event chains within the task. . By task identifier It consists of multiple task-specific disease process event chains, with each chain corresponding to a task-specific association index. and by those belonging to The standard course events are arranged in order of event time, event type, and event identifier. Each chain node retains an event identifier, task-related index, event type, event time, affiliated institution identifier, event summary, and task identifier; each chain also includes node order and disease coverage value. Chain summary. As direct input to the next step, the chain node is used to perform event-level selection, the disease coverage value is used to measure the integrity of the chain structure, and the chain summary is used to prove that the selected object comes from the set of disease event chains in the current task.

[0041] Through this step, the standard course event set is established. Converted into a set of in-task pathological event chains This process uses task identifiers to define the task scope, uses intra-task association indexes to form candidate disease courses, uses event time, event type order, and event identifiers to generate stable chains, uses institution identifiers to represent cross-institutional continuous diagnosis and treatment relationships, uses event summaries and chain summaries to form an auditable structure, and uses disease course coverage values ​​to characterize the chain's coverage of four core disease course events: diagnosis, testing, medication, and follow-up. This step transforms dispersed standard disease course events within the medical consortium into continuous disease course objects that can be further authorized and selected in the next step, providing chained input for subsequent event-level federated learning control based on blockchain task authorization boundaries.

[0042] In step S104 of some embodiments, the set of disease event chains within the task is received. And based on the task identifier carried in each chain. Read the fixed task authorization boundaries on the consortium blockchain ,Will The task-specific pathological event chain is converted into a set of task-controlled pathological event chains that are actually usable in the current federated learning task. The above steps have already set the standard course events. The organization is a chain-like object, with each task containing a chain of disease progression events. Each corresponds to an in-task association index. The nodes in the chain have formed a stable order according to event time, event type, and event identifier, and carry the event identifier, task association index, event type, event time, affiliated institution identifier, event summary, task identifier, chain summary, and disease course coverage value. This step performs event-level selection on the chained object, shifting the task authorization boundary on the chain from "task-level record" to "chain node-level training scope." In real-world medical consortium scenarios, the same disease progression chain may include diagnosis and testing at county hospitals, medication at community institutions, and follow-up at primary healthcare centers. Different clinical tasks have different scopes of use for these nodes; for example, a diabetes complication risk prediction task requires a continuous relationship between diagnosis, testing, medication, and follow-up, while a medication safety assessment task focuses more on the relationship between medication nodes and their preceding or following testing or follow-up nodes. This step transforms the task-specific disease progression event chain into a task-controlled disease progression event chain that both conforms to the on-chain authorization boundary and retains the continuous disease progression value of the medical consortium through three factors: authorization matching, disease progression coverage, and node continuity.

[0043] Medical consortium collaborative indexing service or consortium blockchain side task record component reading Then, first follow the task identifier in the chain record. Retrieve the corresponding on-chain task authorization boundary . This includes constraints on the target disease, permitted participating institutions, permitted event types, permitted disease duration, and output granularity. The system then reads the disease event chain within the task one by one. Nodes in And generate an authorization matching value based on the node field. Authorization matching value The nodes are determined by the results of four comparisons. Task identifier and Consistency, Node The event type belongs to Allowed event types in the node The logo of the affiliated organization belongs to Allowed participating institutions, nodes The time of the event falls into The allowed duration of disease course. For the same Generate and enter The standard course of events, the above four items should be met under normal circumstances, and the system will match the node-level authorization value accordingly. Recorded as 1; if the task identifier, event type, affiliated organization identifier, or event time corresponding to the node is consistent with the current on-chain task authorization boundary. If the records are inconsistent, then The value is set to zero, preventing the node from entering the subsequent controlled disease event chain. This value method originates from set membership judgment and logical conjunction rules in mathematics, which form a node-level gating result through the conjunction relationship of multiple Boolean judgments. In this invention, this rule is used to transform the task authorization boundary on the chain into the admission basis for each disease chain node.

[0044] After obtaining the authorized matching value Then, the system further calculates the continuous values ​​of the nodes. Node continuum values ​​are used to describe nodes. In the chain The connection between a node and its adjacent authorized nodes is directly determined by the chain node order and the authorized matching values ​​of the adjacent nodes. When a node... When there are adjacent nodes with an authorization matching value of one on both the left and right sides, Choose one; when node When there is an adjacent node with an authorized matching value of one only on the left or only on the right, Take half; when node When there are no adjacent nodes with an authorized matching value of one on either the left or right side Take zero. Where, when the chain... When there is only one node and that node has an authorization match value of one, The score is halved. This setting gives higher structural ratings to events in the middle of a continuous disease course, medium structural ratings to events connected only on one side (such as the beginning or end of a chain), and low structural ratings to isolated events. For chronic disease management tasks within a medical consortium, when diagnosis, testing, medication, and follow-up form a sequential chain, nodes better reflect the continuous treatment process. For candidate chains with only a single event, the node still retains the possibility of entering early screening tasks, but its continuity rating is lower than that of intermediate nodes in a complete chain.

[0045] Event Admission Values The calculation is based on the weighted linear evaluation method in decision analysis. The original form of this method synthesizes multiple normalized evaluation items according to their weights into a comprehensive evaluation value, which is used to form a comparable ranking or admission judgment among multiple candidate objects. This invention makes two modifications to this original idea: firstly, it authorizes the matching value... First, it is set as an outer gating system, allowing the on-chain task authorization boundary to determine whether a node is eligible to enter the training range; second, it sets the disease course coverage value. The node continuity values ​​calculated in this step Together, these factors form the structural evaluation criteria, ensuring that node admission considers both the coverage of the four core events (diagnosis, testing, medication, and follow-up) within the disease progression chain and the node's position within the continuous disease progression. The event admission value is calculated by multiplying the disease progression coverage weight by the disease progression coverage value to obtain a second data point; subtracting the preset number from the disease progression coverage weight and multiplying by the node continuity value to obtain a third data point; finally, adding the second and third data points and multiplying by the authorization matching value to obtain the event admission value. The resulting event admission rules are as follows: ; in, Represents a chain Middle node The event admission value is calculated in this step and then written into the controlled chain node record; Represents a chain The standard disease process event nodes to be judged are derived from the disease process event chain within the task. Represents a node The authorization matching value is determined by the node's task identifier, event type, event time, and affiliated organization identifier, and then compared with the on-chain task authorization boundary. The comparison yielded the following results; This indicates the weight of disease course coverage, which is set by the medical consortium in the current task configuration; Represents a chain The disease course coverage value; Represents a node The continuous values ​​of the nodes are determined by the nodes. In the chain The authorization matching status of adjacent nodes is determined; This indicates the event admission threshold for the current task, derived from the task identifier. The bound on-chain task authorization configuration, and Greater than zero; Indicates a chain The task-controlled disease process event chain is formed after event-level selection; Represents a node Inclusion when the right-side admission criteria are met That is, if the event admission value is greater than or equal to the event admission threshold, the corresponding node is selected into the task-controlled disease process event chain. When When taking zero, It is directly zero, and because If the value is greater than zero, the node will not enter the task-controlled disease process event chain; when Take a moment, It is determined by both the chain-level coverage and the degree of node continuity.

[0046] It is a binary quantity. , and All are dimensionless access evaluation quantities. Preferred to be limited to to Within the range, Preferred to be limited to to Within the specified scope, this information is written into the on-chain task authorization configuration along with the task risk level, the number of target event types, and output granularity constraints. If Setting the threshold too high can lead to a situation where no controlled chains meet the threshold for a given task. In this case, the system will not initiate the current round of federated training. Instead, it will record the task status as insufficient training scope and write the summaries of the failed chains and the node admission values ​​to the off-chain task log or the on-chain state summary. This process prevents the generation of a model when the training scope is empty or the authorization conditions are not met.

[0047] The above calculations can be further explained by combining them with a task to predict the risk of diabetes complications. This assumes an on-chain task authorization boundary. The following entities are permitted to participate: County People's Hospital (County A), Community Health Service Center (Community C), and Township Health Center (Town B). Permitted event types include diagnostic events, laboratory events, medication events, and follow-up events. The permitted disease duration covers January to March 2026. The event inclusion threshold is as follows. The weight of disease course coverage is 0.5. It is 0.6. A certain task's disease process event chain. Disease course coverage value The chain consists of four nodes: a diagnosis event at County A People's Hospital, a laboratory test event at County A People's Hospital, a medication event at Community Health Service Center C, and a follow-up event at Township Health Center B. The task identifier, event type, event time, and affiliated institution identifier of each node are consistent with... Matching, therefore the four nodes All are one. The chain-head diagnostic event only has an authorized matching node on the right side. Substituting one-half into the equation, we get... The middle inspection event and medication event both have authorized matching nodes on their left and right sides. Substituting one into the equation yields... The tail-end follow-up event only has an authorized matching node on the left. Substituting one-half into the equation, we get... Once the event thresholds for all four nodes are met, the system generates a task-controlled disease progression event chain in the original chain order: "diagnosis event - laboratory event - medication event - follow-up event". The other chain contains only diagnostic and laboratory events from the same institution, and the calculated disease coverage value is... The value is 0.4, and both nodes are related to... Both matches exist on only one side, and their authorized matching nodes are present. Both are half, under the same configuration If the value is below the threshold, the chain will not form a controlled training chain in the current complication risk prediction task. For early screening tasks, a lower threshold can be used for task configuration. For tasks that emphasize long-term continuous management, a higher task configuration can be adopted. This allows chains with continuous relationships in diagnosis, testing, medication, and follow-up to be included in the training scope.

[0048] After the node selection is completed, the system follows the original chain. The nodes are sequentially connected to form a task-controlled disease process event chain, connecting all nodes that have reached the event admission threshold. .Enter Each node retains the event identifier, task-related index, event type, event time, affiliated organization identifier, event summary, task identifier, and event admission value. The affiliated institution identifier will be used in the next step to locate which medical institution accessed the local records to participate in federated learning training. The event summary will be used in the next step, training audit log, to prove that the training node originated from the controlled chain output in this step. Event admission value. and disease course coverage value This will serve as input for the next step of determining event contribution. If the original chain is "diagnosis event - testing event - medication event - follow-up event", and all four nodes have reached the event admission threshold, the controlled chain will maintain this order; if the institution identifier corresponding to the medication event does not fall into the threshold... The scope of allowed participating institutions, then the node's Zero, If the threshold is zero, the system will connect the diagnostic events, test events, and follow-up events that have reached the threshold into a controlled chain in the original chain order. The resulting controlled chain retains the continuous disease progression structure allowed by the current task and provides a training range that can be directly located to the institution's local records for the next step.

[0049] If only some nodes in a certain original chain enter The system retains the original chain digest and the event digest state of the unadmitted nodes, but the local training list for the next step only includes the entries. If the deletion of a node results in adjacent nodes not being directly consecutive in the original chain, the controlled chain still connects the remaining nodes in their original relative order, and stores the node spacing or missing node count in the controlled chain record for auditing purposes to confirm that the controlled chain was selected from the original chain. This avoids implicitly including unauthorized nodes in the training process while preserving the structural correspondence before and after authorized selection.

[0050] The system also generates a controlled chain summary for each task-controlled disease process event chain. The controlled chain summary is generated by entering... The node event digests are concatenated according to the controlled chain order and then securely hashed. This hash, along with the original chain digest, is written to the controlled chain record. The original chain digest points to the task-specific disease event chain from which the controlled chain originates, while the controlled chain digest identifies the composition and order of nodes actually entering the training candidate range under the current task. For example, if the original chain contains four nodes and the controlled chain retains three, the original chain digest corresponds to the ordered event digests of the four nodes, and the controlled chain digest corresponds to the ordered event digests of the three selected nodes. When initiating local federated learning training in the next step, the scope of events invoked for training can be confirmed based on the controlled chain digest, node event digests, and the organization identifier. Consistent.

[0051] Output granularity constraints in the on-chain task authorization boundary are written along with the task-controlled disease process event chain. Output granularity constraints are used to indicate the form of shared results to be published after the next step completes federated learning training, such as model service identifiers, risk stratification results, or statistical results. This step binds output granularity constraints to the task-controlled disease event chain, ensuring that the training object and the result publication boundary remain consistent under the same task object. For multi-institutional collaborative tasks within a medical consortium, subsequent aggregators, member institutions, and regulatory nodes can follow the task identifier... The original chain summary, controlled chain summary, node event summary, and output granularity constraints trace the correspondence between training objects and shared results.

[0052] In the engineering implementation, this step is triggered by the task recording component on the consortium blockchain side, and the off-chain collaborative index service performs node admission calculations and submits the summary information of the controlled chain record to the consortium blockchain. The collaborative index service reads... After recording the chain record and node record, read the task identifier in the chain. Generate authorized matching values ​​node by node Generate continuous node values ​​based on the authorization matching status of adjacent nodes. Read the disease course coverage value Substituting into the event admission value calculation formula, we get The event access threshold has been reached. The nodes are arranged in the original chain order. The system then generates a controlled chain summary and writes the task-related association index, original chain summary, controlled chain summary, selected node event summary, affiliated institution identifier, event admission value, disease coverage value, and output granularity constraints into the task's controlled disease event chain record. Each node that has been evaluated saves its event summary and admission status, enabling subsequent audits to confirm the processing result of that node under the current task.

[0053] This step outputs a set of controlled disease process event chains. . By task identifier Multiple task-controlled disease process event chains Composition, each Originating from a chain of disease progression events within a task It is formed by connecting chain nodes that have reached the event admission threshold in the original chain order. Each controlled chain node retains the event identifier, task-related index, event type, event time, affiliated institution identifier, event summary, task identifier, and event admission value; each controlled chain retains the original chain summary, controlled chain summary, and disease coverage value. Output granularity constraints. As direct inputs to the next step, the affiliated institution identifier is used to locate the range of events that can participate in training locally in each medical institution, the event summary is used to confirm the source of training nodes, the event admission value and the disease course coverage value are used to determine the event contribution reference when subsequent federated learning aggregation, and the output granularity constraint is used to control the way shared results are published.

[0054] This step involves setting up a chain of disease progression events within the task. Transformed into a task-controlled set of disease process event chains This process defines the authorization boundaries for on-chain tasks. Convert to node-level authorization matching values, and include disease course coverage values. With node continuous values Jointly introduce event admission values Then, a controlled chain that is actually trainable for the current task is formed according to the event admission threshold. This step binds on-chain authorization, disease progression continuity structure, and federated learning training scope in the same chain object, providing explicit input for the next step of executing local federated learning training, aggregation, and controlled sharing of results publication.

[0055] In step S105 of some embodiments, the task-controlled disease process event chain set output from the previous step is inherited. ,by This serves as the execution basis for this federated learning training, model aggregation, shared result publication, and on-chain auditing. The system has already recorded each task-controlled disease process event chain. Each controlled chain node includes its event identifier, task-related index, event type, event time, affiliated organization identifier, event summary, task identifier, and event admission value. Furthermore, each controlled chain also carries a summary of the original chain, a summary of the controlled chain, and a disease course coverage value. And output granularity constraints. This step first assigns controlled chain nodes to corresponding medical institutions according to their institution identifiers. Then, each institution uses the original business records corresponding to the controlled chain nodes locally to complete the training. Subsequently, the aggregator calculates the institution's contribution weight based on the event admission value and disease course coverage value and completes the federated aggregation. Finally, the controlled shared results are published according to the output granularity constraints, and the training scope, aggregation weights, model version, and shared results are written into the consortium blockchain audit record. Thus, the task-controlled disease course event chain formed in the previous step no longer remains within the training candidate range, but is used to actually drive local training, parameter aggregation, and the publication of shared results.

[0056] Medical Consortium Federated Learning Scheduling Component Reading Subsequently, a local training list is generated for each medical institution based on the institution identifier of each controlled chain node. The local training list includes a task identifier, controlled chain summary, event identifier, event type, event time, event summary, intra-task association index, and event admission value. After receiving the local training list, the medical institution locates the standard medical record generated in step S101 in its event cache based on the event identifier, and then locates the original business record in the hospital's business system based on the local reference relationship saved in the standard medical record event. For diagnostic events, the corresponding diagnostic record is located in the electronic medical record system or outpatient / inpatient diagnostic forms; for laboratory events, the corresponding report record is located in the laboratory information system; for medication events, the corresponding medication record is located in the prescription system or medical order system; and for follow-up events, the corresponding follow-up record is located in the primary care chronic disease follow-up system or family doctor contract follow-up system. Before local training, the medical institution uses the event summary in the local training list to verify consistency with the event summary in the standard medical record event; after verification, it proceeds according to the task identifier... Local training samples are constructed based on the corresponding target disease and event type. For example, in the task of predicting the risk of diabetes complications, diagnostic events provide the target disease category, testing events provide the test category related to diabetes management and the test results after local normalization, medication events provide the drug category and medication stage, and follow-up events provide the follow-up conclusion category and follow-up interval. The above training samples are generated locally by the medical institution, and the federated learning scheduling component receives local model parameters or parameter updates.

[0057] Loading and task identification of participating organizations The model is bound to the same federated learning model structure. For tasks such as chronic disease risk prediction, complication risk stratification, or medication risk assessment, the model adopts a structured disease course event input structure: the input layer receives a structured feature vector generated by controlled chain nodes, which includes event type encoding, event time interval encoding, diagnosis category encoding, test category and locally normalized test value, medication category, follow-up conclusion category, and disease course location encoding; the first hidden layer is a fully connected layer containing sixty-four computational units and employing modified linear activation to learn the combined relationships between diagnosis, test, medication, and follow-up; the second hidden layer is a fully connected layer containing thirty-two computational units and employing modified linear activation to form a compressed representation of disease course segments; the output layer is configured according to the output granularity constraints in the task authorization boundary on the chain. When the task is binary risk prediction, one output unit is set and the risk probability is output; when the task is multi-level risk stratification, the number of output units is set consistent with the number of risk levels and the probabilities of each level are output. Each institution completes training locally using the same model structure and training epochs configuration. After training, they submit local model parameters or parameter updates, along with task identifiers, controlled chain summaries, and event summaries of participating nodes, for the aggregator to verify the local training scope. The consistent relationship.

[0058] The model structure, input feature order, missing value imputation method, local normalization rule, training epochs, learning rate, batch size, and stopping criteria are all defined by the task identifier. The bound model configuration file is determined, and a model configuration summary is written to the consortium blockchain audit field upon task initiation. Each institution verifies its model configuration summary before local training; only those summaries match participate in the current training round. If an institution lacks a certain type of event feature, it is handled according to the missing value marker or mask field in the model configuration, rather than changing the input dimensions itself. Model parameters or parameter updates are signed with the institution's private key before submission to the aggregator and transmitted via a secure channel or secure aggregation protocol. The aggregator only accepts parameter submissions from authorized participating institutions that have consistent signatures, task identifiers, model configuration summaries, and controlled blockchain summaries. This process ensures a defined model structure and parameter source for the federated learning process, preventing aggregation failures caused by inconsistent model dimensions or training ranges among different institutions.

[0059] After receiving the local model parameters and event summaries submitted by each medical institution, the aggregator first compares the submitted event summaries with... The event summaries of the controlled chain nodes are checked against the data, and then the contribution weight of each medical institution in this task is calculated. The submitted event summaries are those included in the local training list. Before local training, medical institutions use these event summaries to check their consistency with the event summaries in their local standard disease course events. After training, the actual event summaries used are submitted with the data. Submitted together with the aggregator to prove that the local model parameters come from The training scope is limited. The initial source of this weight calculation is the weighted average normalization idea in numerical computation, that is, first calculate the contribution of each participating object, and then divide each contribution by the total contribution to obtain the normalized weight. Traditional federated average algorithms mostly use the number of local samples as the contribution. This invention transforms the contribution to the contribution of task-controlled disease process events, so that the weight of the institution is jointly determined by the event admission value of the controlled chain node it holds and the coverage of the disease process chain it belongs to. During the calculation, the aggregator first assigns the weight to the event belonging to the first participating object. A set of controlled chain nodes of home medical institutions Then, the institution's contribution is calculated based on the event admission value of each node and the disease coverage value of the controlled chain to which that node belongs. Specifically, the disease coverage enhancement coefficient is multiplied by the disease coverage value, and then added to a preset number to obtain the fourth data point. This fourth data point is then multiplied by the event admission value to obtain the node contribution of the controlled chain node. The node contributions corresponding to all controlled chain nodes of the medical institution are summed to obtain the controlled event contribution. The controlled event contribution is then divided by the sum of all controlled event contributions to obtain the aggregate weight. The formula is shown below: ; in, Indicates the first The number of controlled events contributed by each medical institution in this mission; express The organization to which it belongs is identified as the No. A set of controlled chain nodes in a home healthcare institution; Represents a set One of the controlled chain nodes; Indicates a controlled chain node Event admission criteria; This indicates the disease course coverage enhancement coefficient, which is set by the medical consortium in the task configuration. Represents a node The disease course coverage value corresponding to the controlled chain; Indicates the first The aggregation weight of each medical institution in this federal aggregation; This represents the sum of controlled event contributions from all participating institutions. This formula is derived from a weighted average normalized form, where... This indicates the admission strength of a node in the current task. This indicates the enhancing effect of the completeness of the disease course on the node's contribution; when a chain covers more key stages such as diagnosis, testing, medication, and follow-up, the nodes on that chain receive a higher contribution in the aggregation, thus enabling a small number of events in the continuous disease course chain, such as primary care follow-up and community medication, to be reflected in the institutional aggregation weight.

[0060] , , and All are dimensionless contribution evaluations or normalized weights. The coefficients are dimensionless and nonnegative, preferably limited to... to Within the scope. When an institution has no controlled chain nodes, it will not participate in this round of aggregation weight calculation; when all participating institutions have... When the value is zero, the aggregator does not generate. Instead, it records the task status as having no effective contribution. All calculated by the aggregator... The sum should be one, and the weight calculation input, weight result, and list of participating institutions should be written to the audit log or off-chain verifiable log.

[0061] When performing calculations in conjunction with real-world tasks, let's assume that in a certain diabetes complication risk prediction task, the disease duration coverage enhancement coefficient... Set to 0.5. The disease course coverage value of a complete controlled chain is one. County A People's Hospital holds diagnostic events and laboratory events, with event admission values ​​of 0.8 and 1 respectively. Therefore, its contribution is... Community Health Service Center C holds medication-related events, with an event access value of one; therefore, its contribution is... Township Health Center B holds follow-up events, with an event admission threshold of 0.8. Therefore, its contribution is: The total contribution of the three institutions is The corresponding aggregation weights are respectively , , This calculation process enables county hospital diagnoses and tests, community health centers' medication administration, and primary healthcare centers' follow-up visits to participate in the model's aggregation weight determination based on the event admission results and disease course coverage in the controlled chain.

[0062] After calculating the aggregation weights for each institution, the aggregator performs federated aggregation on the local model parameters submitted by each medical institution. The initial source for this aggregation is the classic federated averaging algorithm, the core of which is a weighted summation of parameters from participating parties with the same model structure. This invention, based on this algorithm, uses the aforementioned task-controlled disease event contribution weights. Instead of simply weighting by sample size, the aggregation process is linked to on-chain authorization boundaries, event-level selection results, and disease course coverage. The aggregation calculation is expressed as: ; in, Indicates the identifier of this task The corresponding aggregated federated model is generated and registered by the aggregator as a model version identifier; The identification of the medical institutions participating in this federal learning mission; The expression represents the result of the calculation of the previous formula. Aggregated weighting of medical institutions; Indicates the first The set of model parameters submitted by a medical institution after local training; this set of model parameters corresponds to the task identifier. The same model structure is used for binding. This formula follows the parameter-weighted summation form of the federated average algorithm, but modifies the source of weights to the contribution weights of task-controlled disease progression events. For any parameter position in the model, the aggregator follows the same set of... Summing the parameters for each institution. For example, at a certain parameter position, the parameter value submitted by County People's Hospital A is 0.62, the parameter value submitted by Community Health Service Center C is 0.58, and the parameter value submitted by Township Health Center B is 0.60. Using the aforementioned weights of 0.5, 0.278, and 0.222, the aggregated parameter at that position is... The aggregator performs the same calculations at all parameter positions in the model to obtain the federated model. .

[0063] and This refers to a set of parameters under the same model structure. It can be a parameter vector, tensor set, or parameter table in a model file arranged in a fixed order. Only parameters with identical names, dimensions, and model configuration summaries are allowed to participate in weighted aggregation. If a secure aggregation protocol is used, the aggregator can obtain the weighted aggregation result after ciphertext mask cancellation or secure summation, without individually checking the plaintext parameter updates for each institution. If the task configuration requires differential privacy, each institution adds pruning and noise reduction according to the task configuration before local submission and writes the privacy parameter summary to the audit log. These security measures do not change the mathematical meaning of the aggregation formula, but only limit the implementation method of model parameter transmission and the aggregation process.

[0064] Federal Model After generation, the system follows The output granularity constraints bound to the chain form controlled shared results. These output granularity constraints originate from the on-chain task authorization boundaries. The system outputs the results along with the task-controlled disease progression event chain. If the output granularity constraint indicates that the model service should be published, the system will publish it. The system identifies the model version, applicable task, scope of eligible institutions, and service interface. Medical consortium member institutions access the model service according to the task's authorized scope. If the output granularity constraint indicates the release of risk stratification results, the system converts the model output into low-risk, medium-risk, or high-risk levels based on the risk threshold configured for the task and releases the risk level results to the authorized institutions. If the output granularity constraint indicates the release of statistical results, the system releases summary results within the task scope, such as the number, proportion, or institution-level trend results for each risk level. Taking the diabetes complication risk prediction task as an example, if the output granularity constraint is a risk stratification result, the system converts the model's output risk probability into low-risk, medium-risk, and high-risk levels according to the task's configured threshold and releases the risk levels as controlled shared results to member institutions within the task's authorized scope.

[0065] When the system publishes controlled sharing results, it simultaneously archives the on-chain audit logs. The audit logs include task identifiers. Original chain digest, controlled chain digest, participating institution identifiers, event digests of the nodes used, and aggregate weights of each institution. The system includes a federated model version identifier, a controlled shared result identifier, and output granularity constraints. The original chain summary points to the disease event chain within the task, the controlled chain summary points to the task's controlled disease event chain, the node event summary identifies the chain node that actually enters training, the participating institution identifier and aggregation weight record each institution's contribution to this aggregation, the federated model version identifier locates the federated model obtained from this aggregation, and the controlled shared result identifier locates the published model service, risk stratification results, or statistical results. Medical institutions locally store training-related local records and training logs, while the consortium blockchain stores task status, summaries, and version records. The medical consortium's management or regulatory nodes can verify the process from the formation of the controlled chain to the publication of results by following the task identifier, original chain summary, controlled chain summary, node event summary, model version identifier, and shared result identifier.

[0066] On-chain audit logs do not record the patient's plaintext identity, original diagnostic values, complete model training samples, or complete model parameter files. Instead, they record a summary, identifier, version, and permission scope. Model files, training logs, feature processing logs, and local record references are stored in off-chain controlled storage and located via on-chain model version identifiers or log summaries. If a task is subsequently withdrawn, shared results are corrected, or authorization expires, the system adds a state change record to the consortium blockchain and sets the corresponding model service or result interface to a disabled or read-only audit state. This process ensures that the lifecycle of shared results is also constrained by task authorization boundaries and on-chain audit logs.

[0067] This step outputs the controlled sharing result. and on-chain audit records . This represents the shared results generated according to output granularity constraints. Specifically, it can be a federated model service, risk stratification results, or statistical results, identified by the task. Determined together with the shared result identifier; The audit logs written to the consortium blockchain include at least the task identifier, the original chain summary, the controlled chain summary, the participating institution identifier, the node event summary, the aggregation weight, the federated model version identifier, the controlled shared result identifier, and the output granularity constraint. For use by member institutions of the medical consortium within the authorized scope. This is used to prove that the shared result was... The defined task-controlled disease event chain is obtained through local training and federated aggregation.

[0068] Through this step, a task-controlled disease process event chain is established. The process is transformed into the actual scope of federated learning training. Each medical institution completes model training locally by calling corresponding records based on the controlled chain nodes. The aggregator calculates the institution's contribution weight based on the event admission value and disease course coverage value and forms a federated model. The system then publishes the controlled shared results according to the output granularity constraints and solidifies the on-chain audit records. This step ensures that the blockchain task authorization boundary, disease course event chain, federated learning training, result publication, and audit records are all under the same task identifier. This forms a closed loop, completing the process of secure data sharing within the medical consortium.

[0069] Steps S101 to S105 of this embodiment involve sending the task authorization boundary to the medical institutions corresponding to the allowed participating institutions, and obtaining the standard disease course events found by each medical institution based on the task authorization boundary. Each standard disease course event corresponds to a patient master index, and the task authorization boundary includes a task identifier and allowed participating institutions. Message authentication is performed based on the task identifier and patient master index to obtain the task-internal association index corresponding to each standard disease course event. Standard disease course events corresponding to the same task-internal association index are grouped into a task-internal disease course event chain. The number of event types and cross-institutional continuity markers of the task-internal disease course event chain are obtained. The disease course coverage value of each task-internal disease course event chain is calculated based on the number of event types, cross-institutional continuity markers, a preset configuration coefficient, and a preset total number of event types. The authorization matching value and node continuity value of each node in the task-internal disease course event chain are obtained. The event admission value of each node is calculated based on the authorization matching value, disease course coverage value, node continuity value, and a preset disease course coverage weight. If the event admission value is greater than or equal to a preset event admission threshold, the corresponding node is selected into the task-controlled disease course event chain. A local training list is generated for each controlled chain node in the controlled disease event chain. Local model parameters are obtained for each medical institution based on the local training list. The aggregation weight of each medical institution is calculated based on the event admission value, disease coverage value and preset disease coverage enhancement coefficient corresponding to all controlled chain nodes. Federated aggregation is performed based on the aggregation weight and local model parameters to obtain the federated model. This improves the prediction accuracy of the aggregated model while ensuring secure data sharing within the medical consortium.

[0070] Please see Figure 2 This application also provides a blockchain-based and federated learning-based medical consortium data security sharing system, which can realize the above-mentioned blockchain-based and federated learning-based medical consortium data security sharing method. The system includes: The acquisition unit 201 is used to send the task authorization boundary to the medical institutions corresponding to the allowed participating institutions, and to acquire the standard disease course events found by each medical institution according to the task authorization boundary; wherein, the standard disease course events correspond to the patient master index, and the task authorization boundary includes the task identifier and the allowed participating institutions; The authentication unit 202 is used to authenticate messages based on the task identifier and the patient master index, obtain the intra-task association index corresponding to each standard disease course event, and form an intra-task disease course event chain by combining the standard disease course events corresponding to the same intra-task association index. The first calculation unit 203 is used to obtain the number of event types and cross-institutional continuous markers of the disease event chain within the task, and to calculate the disease coverage value of each disease event chain within the task based on the number of event types, cross-institutional continuous markers, preset configuration coefficients and preset total number of event types. The second calculation unit 204 is used to obtain the authorization matching value and node continuity value of each node in the disease course event chain within the task, and calculate the event admission value of each node based on the authorization matching value, disease course coverage value, node continuity value and preset disease course coverage weight. If the event admission value is greater than or equal to the preset event admission threshold, the corresponding node is selected into the task controlled disease course event chain. Aggregation unit 205 is used to generate a local training list for each controlled chain node in the task-controlled disease course event chain, obtain the local model parameters of each medical institution based on the local training list, calculate the aggregation weight of each medical institution according to the event admission value, disease course coverage value and preset disease course coverage enhancement coefficient corresponding to all controlled chain nodes of each medical institution, and perform federated aggregation according to the aggregation weight and local model parameters to obtain the federated model.

[0071] The specific implementation of this blockchain-based and federated learning-based medical consortium data security sharing system is basically the same as the specific implementation of the blockchain-based and federated learning-based medical consortium data security sharing method described above, and will not be repeated here.

[0072] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A method for secure data sharing within a medical consortium based on blockchain and federated learning, characterized in that: The method includes: The task authorization boundary is sent to the medical institutions corresponding to the allowed participating institutions, and the standard disease course events found by each medical institution according to the task authorization boundary are obtained; wherein, the standard disease course events correspond to the patient master index, and the task authorization boundary includes the task identifier and the allowed participating institutions; Message authentication is performed based on the task identifier and the patient master index to obtain the intra-task association index corresponding to each standard disease course event, and the standard disease course events corresponding to the same intra-task association index are formed into an intra-task disease course event chain. Obtain the number of event types and cross-institutional consecutive markers of the disease course event chain within the task, and calculate the disease course coverage value of each disease course event chain within the task based on the number of event types, the cross-institutional consecutive markers, a preset configuration coefficient, and a preset total number of event types; Obtain the authorization matching value and node continuity value of each node in the disease course event chain within the task. Calculate the event admission value of each node based on the authorization matching value, the disease course coverage value, the node continuity value, and the preset disease course coverage weight. If the event admission value is greater than or equal to the preset event admission threshold, the corresponding node is selected into the task-controlled disease course event chain. A local training list is generated for each controlled chain node in the controlled disease event chain of the task. Local model parameters of each medical institution are obtained based on the local training list. The aggregation weight of each medical institution is calculated according to the event admission value, the disease coverage value and the preset disease coverage enhancement coefficient corresponding to all controlled chain nodes of each medical institution. Federated aggregation is performed according to the aggregation weight and the local model parameters to obtain the federated model.

2. The method for secure data sharing in a medical consortium based on blockchain and federated learning according to claim 1, characterized in that, The task authorization boundary also includes output granularity constraints. After performing federated aggregation based on the aggregation weights and the local model parameters to obtain the federated model, the method further includes: If the output granularity constraint indicates publishing a model service, then publish the model version identifier, applicable task identifier, scope of callable organizations, and service interface identifier of the federated model. If the output granularity constraint indicates that the risk stratification results are to be published, then the model output is converted into a low-risk, medium-risk, or high-risk level according to the risk threshold configured in the task, and the risk level results are published to the authorized agency. If the output granularity constraint indicates that statistical results are to be published, then the summary results within the scope of the task are published.

3. The method for secure data sharing in a medical consortium based on blockchain and federated learning according to claim 1, characterized in that, The acquisition of the number of event types and cross-agency continuous markers in the intra-task disease event chain includes: The event types within the disease process event chain of the task are statistically analyzed to obtain the number of event types. Determine whether there are adjacent nodes with different institutional identifiers in the disease event chain within the task. If the determination result is yes, the cross-institutional consecutive marker is one; if the determination result is no, the cross-institutional consecutive marker is zero.

4. The method for secure data sharing in a medical consortium based on blockchain and federated learning according to claim 1, characterized in that, The step of calculating the disease coverage value of each in-task disease event chain based on the number of event types, the cross-agency continuous markers, the preset configuration coefficients, and the preset total number of event types includes: Multiply the configuration coefficient by the cross-organizational continuous marker, and then add it to the number of event types to obtain the first data; The disease course coverage value is obtained by dividing the first data by the sum of the total number of event types and the configuration coefficient.

5. The method for secure data sharing in a medical consortium based on blockchain and federated learning according to claim 1, characterized in that, The step of obtaining the authorization matching value and node continuity value of each node in the disease event chain within the task includes: Determine whether the task identifier of the node is consistent with the task identifier of the task authorization boundary, whether the event type of the node is consistent with the allowed event type of the task authorization boundary, whether the organization identifier of the node belongs to the allowed participating organization of the task authorization boundary, and whether the event time of the node falls within the allowed disease course time range of the task authorization boundary. If the determination results are all yes, the authorization matching value is one; otherwise, the authorization matching value is zero. If the authorization matching value of the previous node and the next node of the current node are both one, then the node continuity value of the current node is one. If the authorization matching value of only one node of the previous node or the next node of the current node is one, then the node continuity value of the current node is half. If the authorization matching value of the previous node and the next node of the current node is zero, then the node continuity value of the current node is zero.

6. The method for secure data sharing in a medical consortium based on blockchain and federated learning according to claim 1, characterized in that, The step of calculating the event admission value for each node based on the authorized matching value, the disease course coverage value, the node continuity value, and the preset disease course coverage weight includes: Multiply the disease course coverage weight by the disease course coverage value to obtain the second data; subtract the preset number from the disease course coverage weight, and then multiply by the node continuity value to obtain the third data. The second data is added to the third data, and then multiplied by the authorization matching value to obtain the event admission value.

7. The method for secure data sharing in a medical consortium based on blockchain and federated learning according to claim 1, characterized in that, The calculation of the aggregate weight for each medical institution based on the event admission value, the disease coverage value, and the preset disease coverage enhancement coefficient corresponding to all controlled chain nodes of each medical institution includes: Multiply the disease course coverage enhancement coefficient by the disease course coverage value, and then add it to a preset number to obtain the fourth data. Multiply the fourth data by the event admission value to obtain the node contribution of the controlled chain node. The controlled event contribution is obtained by summing the node contributions corresponding to all controlled chain nodes of the medical institution, and then by dividing the controlled event contribution by the sum of all controlled event contributions to obtain the aggregate weight.

8. A secure data sharing system for medical consortia based on blockchain and federated learning, characterized in that: The system includes: The acquisition unit is used to send the task authorization boundary to the medical institutions corresponding to the allowed participating institutions, and to acquire the standard disease course events found by each medical institution according to the task authorization boundary; wherein, the standard disease course events correspond to a patient master index, and the task authorization boundary includes a task identifier and the allowed participating institutions; An authentication unit is used to perform message authentication based on the task identifier and the patient master index, obtain the intra-task association index corresponding to each standard disease course event, and form an intra-task disease course event chain by combining the standard disease course events corresponding to the same intra-task association index. The first calculation unit is used to obtain the number of event types and cross-institutional continuous markers of the disease course event chain within the task, and to calculate the disease course coverage value of each disease course event chain within the task based on the number of event types, the cross-institutional continuous markers, a preset configuration coefficient, and a preset total number of event types. The second calculation unit is used to obtain the authorization matching value and node continuity value of each node in the disease course event chain within the task, and calculate the event admission value of each node based on the authorization matching value, the disease course coverage value, the node continuity value and the preset disease course coverage weight. If the event admission value is greater than or equal to the preset event admission threshold, the corresponding node is selected into the task-controlled disease course event chain. The aggregation unit is used to generate a local training list for each controlled chain node in the task-controlled disease course event chain, obtain the local model parameters of each medical institution based on the local training list, calculate the aggregation weight of each medical institution according to the event admission value, the disease course coverage value and the preset disease course coverage enhancement coefficient corresponding to all controlled chain nodes of each medical institution, and perform federated aggregation according to the aggregation weight and the local model parameters to obtain the federated model.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the data security sharing method for medical consortia based on blockchain and federated learning as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the data security sharing method for medical consortia based on blockchain and federated learning as described in any one of claims 1 to 7.

Images