Medical image quality control process management method and system based on event traceability

Abstract

The invention relates to the technical field of medical image quality control management, in particular to a medical image quality control process management method and system based on event traceability, and the method comprises the steps: obtaining a case request, creating a corresponding aggregation root instance, and carrying out the use case arrangement based on the aggregation root instance; generating field events of corresponding links based on case arrangement, subscribing and distributing different types of field events through an event bus, and matching corresponding business processing behaviors based on the field events; a completion condition is introduced, the state of the aggregation root instance is updated based on the link where the domain event is located, and whether the completion condition is met is evaluated to determine a process state; and marking the completed domain event as a public event according to the flow state, writing the public event into a sender box, and asynchronously notifying an external system. The method is used for improving the process management effect of medical image quality inspection.

Description

Technical Field

[0001] This application relates to the technical field of medical image quality control management, and in particular to a method and system for medical image quality control process management based on event tracing. Background Technology

[0002] Medical imaging (CT, MRI, DR, etc.) has become a crucial basis for disease diagnosis, treatment planning, and efficacy evaluation. A significant proportion of decisions rely on imaging results, and quality directly determines diagnostic accuracy. Therefore, medical imaging quality control is a key link in ensuring the quality of medical imaging examinations, involving multiple aspects such as technical specifications, equipment management, and diagnostic procedures. The core objective of imaging quality control is to improve image clarity, diagnostic accuracy, and homogenization, while reducing the risk of misdiagnosis due to equipment differences or improper operation.

[0003] The following deficiencies exist in the current medical imaging quality control process management:

[0004] 1. Complex process status management: Traditional quality control systems use database status fields to manage processes. When a process includes multiple stages (DICOM upload, sequence extraction, format conversion, quality verification, etc.), the status transition logic is complex and prone to errors.

[0005] 2. Lack of complete operation audit: Existing systems typically only save the final state and cannot trace the intermediate operation process;

[0006] 3. Insufficient concurrent processing capability: When multiple sequences are transformed simultaneously, state updates are prone to race conditions, leading to data inconsistency;

[0007] 4. Unreliable event notifications: When integrating with external systems, event notifications are easily lost and lack retry and idempotency guarantees. Summary of the Invention

[0008] To improve the process management effectiveness of medical image quality inspection, this application provides a method and system for medical image quality control process management based on event tracing.

[0009] Firstly, this application provides a medical image quality control process management method based on event tracing, employing the following technical solution:

[0010] A medical image quality control process management method based on event tracing includes the following steps:

[0011] Obtain case requests and create corresponding aggregate root instances, then orchestrate use cases based on the aggregate root instances;

[0012] Based on the use case orchestration, corresponding domain events are generated and different types of domain events are subscribed to and distributed through the event bus. Based on the domain events, corresponding business processing behaviors are matched.

[0013] A completion condition is introduced, and the state of the aggregate root instance is updated based on the stage where the domain event is located, and the completion condition is evaluated to determine the process state.

[0014] Based on the process status, the completed domain event is marked as a public event and written to the outbox, and then asynchronously notified to the external system.

[0015] In some embodiments, domain events corresponding to the specified stages are generated based on the use case orchestration, and different types of these domain events are subscribed to and distributed via an event bus. The corresponding business processing behaviors are then matched based on these domain events, including the following steps:

[0016] Based on the case request, a DICOM archiving service is performed and a first event is published after archiving is completed, and the first event is distributed to the first subscriber;

[0017] After waiting for the first subscriber to extract the sequence metadata and complete the verification, publish the second event and distribute the second event to the second subscriber;

[0018] After the second subscriber completes the conversion task scheduling for each sequence metadata, the third event is published. After the format conversion of each sequence metadata is completed concurrently based on the conversion task, a fourth event or a fifth event is published. The fourth event or the fifth event is distributed to the third subscriber, wherein the fourth event indicates that the conversion is successful and the fifth event indicates that the conversion is unsuccessful.

[0019] In some embodiments, the second subscriber is also used to track the progress of the conversion task and synchronously update the record to the sequence progress detail table.

[0020] In some embodiments, the completion condition includes a transformation condition, which involves updating the state of the aggregate root instance based on the stage where the domain event is located and evaluating whether the completion condition is met to determine the process state, including the following steps:

[0021] Wait for the third subscriber to update the state of the aggregate root instance after each fourth or fifth event, and count the fourth or fifth events;

[0022] Waiting for the third subscriber to obtain the current transfer conditions;

[0023] If the transition condition requires all sequences to be successfully converted, then the transition condition is satisfied when the number of the fifth events is equal to zero after the conversion is completed, and the transition condition is not satisfied when the number of the fifth events is greater than zero.

[0024] If the transition condition is that some sequences are allowed to fail and the failure ratio does not exceed a threshold, then the failure ratio is calculated based on the number of the fourth event or the fifth event, and the transition condition is satisfied when the failure ratio is not greater than the threshold, and the transition condition is not satisfied when the failure ratio is greater than the threshold.

[0025] If the transfer conditions are not met, the third subscriber publishes a sixth event, which corresponds to the process state of process failure.

[0026] In some embodiments, when the conversion condition is met, the completion condition further includes a verification condition, which involves updating the state of the aggregate root instance based on the stage where the domain event is located and evaluating whether the completion condition is met to determine the process state, and also includes the following steps;

[0027] Waiting for the third subscriber to obtain the current verification conditions;

[0028] If the verification condition is that AI quality verification is required, then the third subscriber performs the quality verification and publishes the seventh event after the quality verification is completed, and sends the seventh event to the fourth subscriber;

[0029] If the quality verification passes, the fourth subscriber publishes an eighth event; if the quality verification fails, the fourth subscriber publishes a sixth event. The eighth event corresponds to the process status of successful process completion.

[0030] If the verification condition allows for no verification, then the fourth subscriber directly generates the eighth event.

[0031] In some embodiments, the following steps are also included:

[0032] Extract the tenant field from the aggregate root instance and inherit it to the corresponding domain event;

[0033] All tenants on the event bus are retrieved and tenant topics are configured. The domain event is sent to the matching tenant topic based on the tenant field.

[0034] When the first subscriber, second subscriber, third subscriber, and fourth subscriber corresponding to the tenant perform the business processing behavior, they process the domain events of the tenant topic distribution they subscribed to;

[0035] The event bus also includes a fifth subscriber, which is used to determine whether the tenant field in the domain event matches the tenant topic when the domain event is distributed, and to intercept the domain event and trigger an alarm if they do not match.

[0036] In some embodiments, the following steps are also included:

[0037] Determine whether there is an emergency marker in the case request. If so, the first subscriber selects a key sequence based on the examination type after extracting the sequence metadata.

[0038] The conversion condition obtained by the third subscriber is that all key sequences must be successfully converted, and the verification condition obtained by the third subscriber is that all key sequences must undergo AI quality verification.

[0039] In some embodiments, the completed domain event is marked as a public event and written to the outbox according to the process status, and asynchronously notified to an external system, and the process further includes the following steps:

[0040] Based on the business process table and event table, write the business data and event records corresponding to the public event into the outbox;

[0041] Set up a background task to periodically query the outbox for unpublished events;

[0042] Determine whether the public event has been successfully sent. If yes, mark the public event. If no, automatically retry based on the exponential backoff strategy.

[0043] If the number of automatic retries exceeds the preset value, it will be marked as a dead letter record error and an alarm will be triggered.

[0044] In some embodiments, the following steps are also included:

[0045] Obtain system fault recovery information;

[0046] Load all historical events of the current process into the event table;

[0047] Reconstructing the aggregate root state by replaying events in chronological order.

[0048] Secondly, this application provides a medical image quality control process management system based on event tracing, which adopts the following technical solution:

[0049] An event-based medical image quality control process management system is provided to implement the above method.

[0050] The technical solutions provided by the embodiments of this application have the following technical effects:

[0051] Audit compliance: By fully linking and recording all operations through the aggregate root, the state can be traced back to any point in time;

[0052] System reliability: Through event tracing and outbox mode, data consistency and reliable event publishing are guaranteed, and the system has strong fault recovery capabilities.

[0053] Processing efficiency: Supports high-concurrency sequence conversion, event-appendable writes without lock contention, and outperforms traditional state update methods;

[0054] Business flexibility: The completion condition policy can be configured, supporting a combination of various business rules such as "allow partial failure" and "must pass verification";

[0055] System scalability: Adding a quality control step does not require modifying existing code; it only requires subscribing to the corresponding event, which complies with the open / closed principle.

[0056] Integration capabilities: The event notification interface is provided through the event sender box, which facilitates integration with external systems such as HIS, RIS, and PACS. Attached Figure Description

[0057] Figure 1 This is a schematic diagram of the steps of the medical image quality control process management method based on event tracing provided in this embodiment.

[0058] Figure 2 This is a schematic diagram of domain events corresponding to some business processes in the embodiments of this application.

[0059] Figure 3 This is a schematic diagram of domain events corresponding to some business processes in the embodiments of this application. Detailed Implementation

[0060] To better understand the purpose, technical solutions, and advantages of this application, it has been described and illustrated below with reference to the accompanying drawings and embodiments. However, those skilled in the art should understand that this application can be implemented without these details. In some cases, to avoid obscuring various aspects of this application due to unnecessary description, well-known methods, processes, systems, components, and / or circuits already described at a higher level will not be elaborated upon. It will be apparent to those skilled in the art that various modifications can be made to the embodiments disclosed in this application, and the general principles defined in this application can be applied to other embodiments and application scenarios without departing from the principles and scope of this application. Therefore, this application is not limited to the illustrated embodiments, but conforms to the broadest scope consistent with the scope of protection claimed in this application.

[0061] It should be noted that the descriptions of these embodiments are for the purpose of aiding understanding the present invention, but do not constitute a limitation thereof. Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0062] In the description of this application, "several" means one or more, "more than" means two or more, "greater than," "less than," and "exceeding" are understood to exclude the stated number, while "above," "below," and "within" are understood to include the stated number. The use of "first" and "second" in the description is merely for distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the order of the indicated technical features.

[0063] In the description of this application, the terms "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any one or more embodiments or examples.

[0064] like Figure 1 As shown in the embodiments of this application, a medical image quality control process management method based on event sourcing is disclosed. Specifically, it is based on a system implementation employing domain-driven design and an event sourcing structure. The system architecture mainly includes:

[0065] Interface layer: REST API, Web management interface;

[0066] Application layer: Use case orchestration (submitting cases, handling DICOM, quality verification, etc.);

[0067] Domain layer: QC process aggregation root, domain events, completion strategy;

[0068] Infrastructure layer: event bus, aggregation repository, event dispatch box, conversion scheduler, etc.

[0069] The medical image quality control process management method based on event tracing includes the following steps:

[0070] S100: Obtain case requests and create corresponding aggregate root instances, then orchestrate use cases based on the aggregate root instances.

[0071] The aggregate root is a concept in Domain-Driven Design, representing the root entity of a group of domain objects. It is the entry point and controller of the aggregate. External systems can only access other objects within the aggregate through the aggregate root. The aggregate root guarantees all invariant conditions and business rules within the aggregate. Only the aggregate root can be directly saved to the database, while other objects are usually indirectly persisted as its components.

[0072] This application adopts the aggregate root pattern to manage the entire quality control process. Each quality control process instance serves as an aggregate root, and all state changes are recorded through domain events.

[0073] When a case submission request is received, an aggregate root instance is created. The aggregate root instance is used to orchestrate subsequent business processes and business rules.

[0074] The process orchestration is event-driven, and loosely coupled process orchestration is achieved based on the event bus.

[0075] Loose coupling refers to a design pattern where system components have few dependencies and communicate through clearly defined interfaces or information. This architecture allows components to be modified or replaced independently, improving the system's flexibility and maintainability.

[0076] The core of loose coupling lies in reducing direct dependencies between components. Specifically, components interact only through standardized interfaces, without needing to know each other's internal logic. Both parties only need to adhere to the defined input / output formats.

[0077] S200 generates domain events for corresponding stages based on use case orchestration and subscribes to and distributes different types of domain events through an event bus, matching the corresponding business processing behaviors based on the domain events.

[0078] Aggregate root determines the corresponding business process and domain events through use case orchestration, and distributes domain events at different stages to subscribers subscribed to the event mainline based on the business behavior and business results of each stage, and defines and manages the business processing behavior of each subscriber driven by the domain events.

[0079] Simultaneously, when generating and processing events from different domains, the events are persisted to the event storage. Event persistence to the event storage is a core component of the event sourcing model; by recording event sequence information in storage, it ensures the immutability and traceability of the data.

[0080] The specific domain-specific event-driven quality inspection process will be described in detail later.

[0081] S300 introduces completion conditions and updates the state of the aggregate root instance based on the stage where the domain event is located, and evaluates whether the completion conditions are met to determine the process state.

[0082] The system introduces flexible completion strategies, allowing users to select different completion conditions based on requirements, scenarios, and configurations in different business processes. It also uses domain events to determine whether the completion conditions are met and thus decides the process status of the quality inspection process.

[0083] Different completion strategies correspond to different completion conditions. Different completion conditions determine whether the required strategy conditions have been met each time the system receives different events, based on information such as the number, status, and structure of the events, and generate different quality control process results based on the completion structure.

[0084] S400 marks completed domain events as public events based on process status, writes them to the outbox, and asynchronously notifies external systems.

[0085] A public event is represented as the final result event under the event state change in the domain. When the process is completed, the final domain event is marked as a public event and written to the outbox table through UnitOfWork. The background publisher asynchronously notifies the external system.

[0086] The sender box pattern solves the distributed transaction problem and ensures reliable event publishing.

[0087] This allows for the complete recording of all operations based on the aggregate root, tracing back to the state at any point in time.

[0088] The newly added process steps do not require modification of existing code; they only need to subscribe to relevant events, which complies with the Open / Closed Principle.

[0089] The event sender provides a standardized event notification interface, facilitating integration with external systems such as HIS, RIS, and PACS.

[0090] like Figure 2 As shown, in other embodiments, domain events for corresponding stages are generated based on use case orchestration, and different types of domain events are subscribed to and distributed through an event bus. The corresponding business processing behaviors are matched based on the domain events, including the following steps:

[0091] S210, based on the case request, performs DICOM archiving service and publishes the first event after archiving is completed, distributing the first event to the first subscriber.

[0092] First, DICOM archiving service is performed based on the submitted cases, and a first event is issued upon completion of archiving. In this embodiment, the first event is the DicomArchived event. The DicomArchived event indicates that DICOM file archiving is complete and includes information such as project number, subject ID, and visit point.

[0093] After the first event is published, the event bus distributes the first event to the first subscriber, which in this application is the sequence extractor.

[0094] S220: After the first subscriber extracts the sequence metadata and completes the verification, the second event is published and distributed to the second subscriber.

[0095] The sequence extractor extracts sequence metadata from DICOM storage and verifies sequence integrity and consistency. Upon completion of extraction and verification, a second event is published. In this embodiment, the second event is the `SequencesExtracted` event, signifying the completion of sequence information extraction. Its domain events include a list of sequence IDs, a list of issues, etc.

[0096] It is important to note that in the subsequent completion conditions, if the project or tenant has enabled the corresponding completion rules, the top-level judgment rule is based on verifying the legality of DICOM. If the sequence extractor determines that there is a fatal error in the sequence when verifying the integrity and consistency of the sequence, it will directly generate the subsequent sixth event (indicating that the quality control process has failed) to report the error and stop the subsequent business process. The second event will only be generated if there is no instruction error.

[0097] The event bus distributes the second event to the second subscriber, which in this embodiment is a conversion scheduler.

[0098] S230, wait for the second subscriber to complete the conversion task scheduling for each sequence metadata and then publish a third event. After the conversion task is completed concurrently for the format conversion of each sequence metadata, publish a fourth or fifth event and distribute the fourth or fifth event to the third subscriber. The fourth event indicates that the conversion was successful and the fifth event indicates that the conversion failed.

[0099] The transformation scheduler first schedules the transformation service to schedule N tasks, where N represents the number of sequence metadata.

[0100] After scheduling is complete, the conversion scheduler distributes several sequence metadata to each scheduled task for subsequent format conversion and publishes a third event. In this embodiment, the third event is the NiftiScheduled event, which indicates that the format conversion task has been scheduled.

[0101] Multiple sequences are converted concurrently, and after each sequence is converted, it is determined whether the conversion was successful. If the conversion is successful, a fourth event is published; otherwise, a fifth event is published.

[0102] In this embodiment of the application, the fourth event is the SequenceConverted event, which indicates that a single sequence conversion is successful. It includes information such as sequence ID and conversion time. The fifth event is the SequenceFailed event, which indicates that a single sequence conversion fails. It includes information such as sequence ID and reason for failure.

[0103] The format conversion is necessary because while the common DICOM format is widely used in medical systems, it often needs to be converted to a more suitable format, such as NIfTI, for analysis in neuroscience, imaging, and other fields. Furthermore, the NIfTI format is easier for AI analysis and processing. Therefore, this application converts DICOM format sequence data to NIfTI format.

[0104] In other embodiments, the second subscriber is also used to track the progress of the conversion task and synchronously update the record to the sequence progress detail table.

[0105] In this embodiment of the application, the second subscriber also includes a progress tracker, which tracks the conversion task of each sequence and records the relevant information in the sequence progress details table when the sequence starts conversion and after the conversion is completed.

[0106] The progress details table is qc_sequence_progress, which contains information such as sequence ID, status, transition time, and failure reason.

[0107] like Figure 3 As shown, in some other embodiments, the completion conditions include transformation conditions, updating the state of the aggregate root instance based on the stage where the domain event is located, and evaluating whether the completion conditions are met to determine the process state, including the following steps:

[0108] S310, wait for the third subscriber to update the state of the aggregate root instance after each fourth or fifth event, and count the fourth or fifth events.

[0109] In this embodiment, the third subscriber is a completion policy processor, which is used to obtain the completion conditions corresponding to the current project / tenant. Each time a fourth or fifth event is received, the completion policy processor updates the conversion counter in the aggregate root instance to keep track of the count. The main objects being counted are the total number of fourth or fifth events received and the fifth event itself, which represents the total number of conversion failures.

[0110] S311, waiting for the third subscriber to obtain the current transfer conditions.

[0111] The completion strategy processor matches the transfer conditions corresponding to the project or tenant based on the unique project field `project_subject_id` or tenant field `tenant_id` corresponding to the aggregate root. The transfer conditions are characterized by the "degree of satisfaction under which transfer determination decision" set by the system rules, mainly including: 1. All sequence conversions must be successful; 2. Some sequence conversion failures are allowed, and the failure rate does not exceed the threshold.

[0112] S312, if the transition condition is that all sequences must be successfully transformed, then the transition condition is satisfied when the number of the fifth event is equal to zero after the transformation is completed, and the transition condition is not satisfied when the number of the fifth event is greater than zero.

[0113] First, based on this condition, the completion policy processor calls the `evaluate_completion()` method each time it receives an event from the second subscriber to determine whether the conversion condition is met. Specifically,

[0114] The system counts the events received from the second subscriber and checks in real time whether a fifth event occurs. If a fifth event occurs, the business activity is stopped and the transition condition is not met. If no fifth event occurs, the evaluate_completion() method is called continuously until the total count reaches the total number of events in the sequence.

[0115] In other words, after all sequence transformations are completed, under this transition condition, only sequences that do not fail to transform are considered to meet the condition; any sequence that fails to transform is considered to not meet the condition.

[0116] S313, if the transition condition is that some sequences are allowed to fail and the failure ratio does not exceed a threshold, then the failure ratio is calculated based on the number of the fourth or fifth events, and the transition condition is met when the failure ratio is not greater than the threshold, and the transition condition is not met when the failure ratio is greater than the threshold.

[0117] Based on this condition, the completion policy processor still calls the `evaluate_completion()` method to determine whether the condition is met each time it receives an event from the second subscriber. Specifically,

[0118] The system counts the events received from the second subscriber and continues to perform subsequent operations when the fifth event is received. The failure rate is calculated by dividing the number of the fifth event by the total number of the fourth and fifth events.

[0119] Each received event is evaluated using the evaluate_completion() method to determine if the failure rate exceeds the threshold. If it does, the current business behavior is interrupted and the conversion condition is directly deemed not to be met. If the failure rate is still not greater than the threshold after all sequences have been converted, the conversion condition is deemed to be met.

[0120] S314 If the transfer conditions are not met, the third subscriber publishes the sixth event, which corresponds to the process status of a failed completion.

[0121] When completion conditions are introduced, if a third subscriber believes that the conversion conditions are not met during the conversion process, a sixth event is directly published. In this embodiment of the application, the sixth event is the CaseFailed event, which indicates that the process is terminated due to an error, including the reason for failure and the failure stage.

[0122] The reasons for failure and the failure stages vary depending on the stage and problem at which the process terminates. For example, if the sequence extractor determines that there is a fatal error in the sequence when verifying the integrity and consistency of the sequence, the sixth event generated is due to a sequence problem, and the failure stage is the sequence extraction stage. If the sixth event is generated and terminated during DICOM data archiving due to data errors, the reason for failure is archiving failure, and the failure stage is the DICOM archiving stage. If the sixth event is generated due to failure to meet the conversion conditions, the reason for failure is too many conversion failures, and the failure stage is the sequence conversion stage.

[0123] like Figure 3 As shown, in some other embodiments, when the conversion condition is met, the completion condition also includes a verification condition. This involves updating the state of the aggregate root instance based on the stage where the domain event occurs and evaluating whether the completion condition is met to determine the process state. The process also includes the following steps:

[0124] S320, waiting for a third subscriber to obtain the current verification conditions.

[0125] Furthermore, some centers or systems may introduce AI quality verification modules to intelligently verify image quality, data quality, and business processes. In systems that meet these functions, verification conditions can be further introduced.

[0126] The verification conditions correspond to the AI ​​quality verification switches configured in the system, which are associated with quality control projects or quality control tenants. Some projects / tenants are required to add and perform AI quality verification (AI quality verification switch on), while other projects / tenants are allowed to not perform AI quality verification (AI quality verification switch off).

[0127] Based on the verification conditions, the system can then determine whether verification needs to be triggered or whether to complete the process directly.

[0128] S321, if the verification condition is that AI quality verification is required, then the third subscriber performs quality verification and publishes the seventh event after the quality verification is completed, and sends the seventh event to the fourth subscriber.

[0129] If the verification condition requires AI quality verification, the policy processor will call the AI ​​verification service to perform image quality assessment.

[0130] After quality verification is completed, a seventh event is published to the fourth subscriber. In this embodiment, the seventh event is the ValidationCompleted event, which signifies the completion of quality verification and includes whether it passed and the verification result. The fourth subscriber is the final processor, which is used to issue domain events that determine the final process status when the final completion conditions are met throughout the entire quality control process.

[0131] S322, if the quality verification passes, the fourth subscriber publishes the eighth event; if the quality verification fails, the fourth subscriber publishes the sixth event. The eighth event corresponds to the process status of successful completion.

[0132] If all quality verifications pass, the final processor will issue the eighth event, which in this application is the CaseCompleted event, signifying that the entire process has been successfully completed.

[0133] If the quality verification fails, the final processor will issue a CaseFailed event and set the corresponding failure reason as the quality verification failed, and the failure stage will be the quality verification stage.

[0134] S323, if the verification condition is to allow no verification, then the fourth subscriber directly generates the eighth event.

[0135] When the verification condition allows for no verification, the fourth subscriber can directly generate a CaseCompleted event when the above conversion conditions are met.

[0136] The eight core domain events defined in this application cover the entire lifecycle of the quality control process. In the entire business process, all domain events inherit from the QcProcessEvent base class and contain unified metadata (event type, project subject ID, timestamp, whether it is a public event, etc.).

[0137] Based on the above solution, this application has the following technical features:

[0138] It supports concurrent transformation of multiple sequences, and its core mechanism is as follows:

[0139] Concurrent scheduling: Upon receiving the second event (SequencesExtracted event), all sequence transformation tasks are scheduled simultaneously;

[0140] Independent events: After each sequence conversion is completed, a fourth event (SequenceConverted event) or a fifth event (SequenceFailed event) is published independently.

[0141] Incremental update: After the policy processor receives each conversion event, it incrementally updates the count of the fourth event (SequenceConverted event) or the fifth event (SequenceFailed event);

[0142] Condition evaluation: After each incremental update, the evaluate_completion() method is called to determine whether the completion conditions are met;

[0143] Trigger verification: When all sequences have been processed and the completion conditions are met, the AI ​​quality verification process is automatically triggered;

[0144] Final completion: After successful verification, the sixth event (CaseFailed event) or the eighth event (CaseCompleted event) is generated and written to the outgoing mail box.

[0145] Through the mechanisms described above, the system can efficiently handle the concurrent conversion of dozens of sequences without waiting for locks.

[0146] The above technical solutions are illustrated by comparison through two simulated scenarios:

[0147] Scenario 1 (Standard Quality Inspection Process): A certain MRI examination requires that all sequences be successfully converted and verified by AI.

[0148] Configuration:

[0149] The completion conditions are require_validation=True (AI validation is required) and max_fail_ratio=0 (maximum failure ratio is 0).

[0150] Number of sequences: 3.

[0151] Execution process:

[0152] 1. The patient completes the MRI scan, and the system receives the corresponding DICOM file for the medical record;

[0153] 2. Publish the first event (DicomArchived event) and extract 3 sequences;

[0154] 3. After extraction is complete, publish the second event (SequencesExtracted event), schedule the transformation task and publish the third event (NiftiScheduled event), and transform the three sequences concurrently;

[0155] 4. The three fourth events (SequenceConverted events) arrive in sequence;

[0156] 5. Assess completion conditions and trigger AI verification;

[0157] 6. Validation passed, publish the seventh event (ValidationCompleted event).

[0158] 7. The eighth event (CaseCompleted event) is released when the final evaluation condition is met.

[0159] 8. Notify the PACS system (Image Archiving and Communication System, the core system for image management) via the outbox, and the process ends.

[0160] Result: The process was completed smoothly, taking approximately 5 minutes, and all events were fully recorded.

[0161] Scenario 2 (Fault-Tolerant Quality Control Process): For a certain task, 30% of sequence conversion failures are allowed, and no AI verification is required.

[0162] Configuration:

[0163] Completion strategy: require_validation=False (allows AI validation to be performed without scheduling), max_fail_ratio=0.3 (maximum failure rate is 30%).

[0164] Number of sequences: 10.

[0165] Execution process:

[0166] 1. Receive historical data DICOM files and publish the first event (DicomArchived event).

[0167] 2. Extract 10 sequences;

[0168] 3. After extraction is complete, publish the second event (SequencesExtracted event), schedule the conversion task and publish the third event (NiftiScheduled event). 10 sequences are converted concurrently, of which two sequences fail due to format issues;

[0169] 4. Publish 2 fifth events (SequenceFailed events) and 8 fourth events (SequenceConverted events);

[0170] 5. Assess completion conditions; failure rate is less than 20% to 30%, no verification required.

[0171] 6. Directly publish the eighth event (CaseCompleted event);

[0172] 7. Notify the system that the process has ended.

[0173] Result: Although some sequences failed, the verification conditions were met, and the process was still marked as complete.

[0174] In other embodiments, the following steps are also included:

[0175] S330, extract the tenant field from the aggregate root instance and inherit it to the corresponding domain event.

[0176] For some third-party image quality control service platforms, which provide services to multiple organizations, the event bus will contain several tenants. It is necessary to solve the problem of preventing resource contention among tenants and allocating resources on demand.

[0177] Therefore, in this embodiment of the application, the tenant_id field is first extracted from the metadata of the aggregate root instance and passed to all domain events generated by the aggregate root to ensure that the events and tenants are strongly bound.

[0178] S331: Obtain all tenants on the event bus and configure tenant topics. Domain events are sent to the matching tenant topics based on the tenant field.

[0179] Because the event bus in this application implements loosely coupled process orchestration, it can ensure that events only circulate within a tenant in a multi-tenant environment. Specifically,

[0180] Create a separate Kafka topic for each tenant, and all subsequent domain events for that tenant will only be sent to its own topic.

[0181] S332, the domain events that handle the distribution of the subscribed tenant's topic when the first, second, third, and fourth subscribers of the tenant perform business processing actions.

[0182] The component will inject a list of tenant themes at the code level. All components of a tenant will subscribe to their own tenant themes in the list based only on the tenant field, thereby achieving data logic isolation. Multiple tenants can reuse the same set of component Pods.

[0183] S333, the event bus also includes a fifth subscriber, which is used to determine whether the tenant field in the domain event matches the tenant topic when the domain event is distributed, and to intercept the domain event and trigger an alarm if they do not match.

[0184] A fifth subscriber, the tenant verification interceptor, has been added to the event bus. It is used to determine whether the tenant field of an event matches the tenant topic. If it does, the subsequent business content is processed. If not, such as when a tenant's event is sent to the tenant B topic, it will be directly intercepted and an alarm will be triggered to prevent data leakage.

[0185] Under this method, all tenant isolation logic is based on the system's aggregate root-domain event-event storage link. Events, aggregate root instances, etc. can be filtered by only the tenant field and topic, without modifying the event replay and state reconstruction mechanism.

[0186] In other embodiments, the following steps are also included:

[0187] S340, determine whether there is an emergency marker in the case request. If so, the first subscriber selects the key sequence based on the examination type after extracting the sequence metadata.

[0188] S341, the transformation condition obtained by the third subscriber is that all key sequences must be successfully transformed, and the verification condition obtained by the third subscriber is that all key sequences must be AI quality verified.

[0189] For certain emergency imaging procedures, such as head CT scans and chest pain REI, it is necessary to overcome asynchronous delay limitations to avoid delaying diagnostic decisions.

[0190] To address the aforementioned issues, this application further determines whether an emergency marker exists in the case request. The emergency marker is a preset marker field. Case requests with an emergency marker are represented as a priority field in the corresponding generated QcProcessEvent base class, containing three levels: HIGH / DEFAULT / LOW. Emergency cases are automatically marked as HIGH upon submission.

[0191] The event bus matches the priority queue, with HIGH-level events preempting the head of the queue to reduce processing latency. When the interface layer receives a case request, it automatically triggers priority assignment based on the emergency identifier of the RIS system.

[0192] Meanwhile, because it is necessary to speed up the quality verification time as much as possible in the emergency department, the completion conditions for emergency department identification are different from those of the regular quality verification process. The difference is that the conversion condition requires all key sequences to be successfully converted, and the verification condition requires all key sequences to undergo AI quality verification.

[0193] In this way, for emergency scenarios, the conditions for the completion of full sequence conversion are skipped, and only key sequences (such as the "axial plain scan sequence" of head CT) are verified. AI verification is also only performed on key sequences, such as checking image clarity and the absence of artifacts.

[0194] In other embodiments, the completed domain events are marked as public events and written to the outbox according to the process status, and are asynchronously notified to external systems, further including the following steps:

[0195] S410 writes the business data and event records corresponding to common events into the outgoing mail box based on the business process table and event table.

[0196] First, it should be noted that the business process table and the event table are both core data tables maintained and associated by the system and used to achieve full lifecycle progress tracking. The core data tables also include the aforementioned sequence progress details, as well as the domain_event_outbox table corresponding to the public event outbox, which contains event ID, event type, aggregate ID, load, whether it has been published, number of retries, etc.

[0197] The business process table corresponds to the main table of the entire quality inspection process, specifically the qc_process table, which records and maintains the following information: status, total number of sequences, number of failures, failure rate, verification results, etc.

[0198] The event table corresponds to the qc_process_event table in the internal event stream storage, which records and maintains the following information: event type, stage, message, and event occurrence.

[0199] By linking these tables, the system can achieve refined progress tracking, status recovery, and audit queries.

[0200] The outgoing mail box needs to simultaneously write business data based on the business process table and event records based on the event table.

[0201] S420, set up a background task to periodically check for unpublished events in the outbox.

[0202] S430 determines whether the public event has been successfully sent. If so, the public event is marked; otherwise, it is automatically retried based on the exponential backoff strategy.

[0203] S440 If the number of automatic retries exceeds the preset value, it will be marked as a dead letter record error log and an alarm will be triggered.

[0204] The configured background task periodically queries all unpublished events in the outbox. If there are events to be published, it will iterate through each event and send it asynchronously to the external system. If there are no events to be published, it will sleep and wait.

[0205] When an event is successfully sent, the system marks the published event and notifies the external system (HIS / RIS / PACS). If the external system confirms receipt, it indicates that the event was successfully sent.

[0206] Marking published events is to ensure that, on the one hand, an event is published at least once, and on the other hand, based on the deduplication mechanism, it ensures that duplicate events will not lead to duplicate processing.

[0207] There are two reasons for failed events: one is that the event failed to be sent in the outbox, and the other is that the event was successfully sent in the outbox but was not received by the external system.

[0208] Regardless of the cause of failure, this application will adopt an exponential backoff retry mechanism for events that fail to send. At the same time, it will further determine in real time whether the number of retries exceeds the limit. If it does, it will mark it as a dead letter in the error log and trigger an alarm. If it does not exceed the limit, it will continue to retries until it is successfully sent and then add a mark.

[0209] In other embodiments, the following steps are also included:

[0210] S500, obtain system fault recovery information.

[0211] S510 loads all historical events of the current process into the event table.

[0212] S520 replays events in chronological order to reconstruct the aggregate root state.

[0213] When a system fault message is received, all historical events of the process are loaded from the event store, the events are replayed in chronological order, the aggregate root state is rebuilt, and subsequent events are processed to ensure process continuity.

[0214] For example:

[0215] Scenario 3: The system crashes during the conversion process and resumes operation after a restart.

[0216] Execution process:

[0217] 1. After the system restarts, an incomplete process (project_subject_id=1234) is detected.

[0218] 2. Load all events for this process from the event store:

[0219] DicomArchived;

[0220] Sequences Extracted (5 sequences);

[0221] SequenceConverted (3 sequences);

[0222] 3. Replay events in sequence to reconstruct the aggregate root state:

[0223] status=CONVERTING;

[0224] total_sequences=5;

[0225] converted_sequences=3;

[0226] 4. Continue waiting for the transition events of the remaining two sequences;

[0227] 5. Two SequenceConverted events were received;

[0228] 6. Evaluation completed, verification triggered, final completion.

[0229] Result: The system successfully recovered to its pre-crash state, the process continued, and no data was lost.

[0230] Based on the above mechanism, the system can be restored to a historical state at any time, achieving complete operation auditing and fault recovery.

[0231] Furthermore, this application periodically saves state snapshots to reduce replay overhead.

[0232] This application also discloses a medical image quality control process management system based on event tracing, used to implement the above method, specifically including:

[0233] The aggregate root module is used to manage the lifecycle of a single quality control process instance, recording all state changes through domain events;

[0234] The event bus module is used to publish and subscribe to domain events, enabling loosely coupled communication between components;

[0235] The event storage module is used to persist events across all domains and supports event replay and state reconstruction.

[0236] The completion strategy module is used to evaluate whether the quality control process meets the completion conditions, and supports a combination of multiple strategies;

[0237] The event mailbox module is used to reliably publish public events to external systems, ensuring that the semantics are sent at least once.

[0238] The sequence progress tracking module records the transition status of each sequence, supporting concurrent processing and fine-grained management.

[0239] The aggregate root module specifically includes:

[0240] Status attributes record the current process status, number of sequences, conversion progress, etc.

[0241] The event generation method generates corresponding domain events based on business operations.

[0242] Event application methods, applying domain event updates to the root state of the aggregate;

[0243] Once the evaluation method is complete, the completion strategy is invoked to determine whether the process is complete.

[0244] Domain events include:

[0245] The DicomArchived event indicates that the DICOM file archiving is complete;

[0246] The SequencesExtracted event indicates that sequence information extraction is complete;

[0247] The NiftiScheduled event indicates that the format conversion task has been scheduled;

[0248] The SequenceConverted event indicates that a single sequence has been successfully converted;

[0249] The SequenceFailed event indicates that a single sequence conversion failed;

[0250] The ValidationCompleted event indicates that quality validation is complete.

[0251] The CaseCompleted event indicates that the entire process has been successfully completed.

[0252] The CaseFailed event indicates that the process terminated due to an error.

[0253] The strategy module supports the following strategies:

[0254] All sequences must be converted successfully;

[0255] Some sequence failures are allowed, but the failure rate shall not exceed a threshold.

[0256] AI quality verification is required;

[0257] Allow completion without verification;

[0258] Any combination of the above strategies.

[0259] The system described in this application is widely used in the following scenarios:

[0260] Quality control process management for large-scale equipment such as MRI, CT, and PET-CT.

[0261] Remote Imaging Center: Centralized quality control for regional imaging centers and third-party imaging centers.

[0262] Clinical trials: Quality control and auditing of imaging data in multicenter trials.

[0263] AI-assisted diagnosis: Data quality control and annotation management before the launch of AI imaging products.

[0264] Image Cloud Platform: Quality control module for cloud PACS and cloud image platform.

[0265] The implementation principle is as follows:

[0266] Audit compliance: By fully linking and recording all operations through the aggregate root, the state can be traced back to any point in time;

[0267] System reliability: Through event tracing and outbox mode, data consistency and reliable event publishing are guaranteed, and the system has strong fault recovery capabilities.

[0268] Processing efficiency: Supports high-concurrency sequence conversion, event-appendable writes without lock contention, and outperforms traditional state update methods;

[0269] Business flexibility: The completion condition policy can be configured, supporting a combination of various business rules such as "allow partial failure" and "must pass verification";

[0270] System scalability: Adding a quality control step does not require modifying existing code; it only requires subscribing to the corresponding event, which complies with the open / closed principle.

[0271] Integration capabilities: The event notification interface is provided through the event sender box, which facilitates integration with external systems such as HIS, RIS, and PACS.

[0272] It should be understood that although the steps in the flowcharts in the accompanying drawings are shown sequentially as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise expressly stated herein, there is no strict order in which these steps are performed, and they may be performed in other orders.

[0273] The above are all preferred embodiments of this application, and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. A medical image quality control process management method based on event tracing, characterized in that, Includes the following steps: Obtain case requests and create corresponding aggregate root instances, then orchestrate use cases based on the aggregate root instances; Based on the use case orchestration, corresponding domain events are generated and different types of domain events are subscribed to and distributed through the event bus. Based on the domain events, corresponding business processing behaviors are matched. A completion condition is introduced, and the state of the aggregate root instance is updated based on the stage where the domain event is located, and the completion condition is evaluated to determine the process state. Based on the process status, the completed domain event is marked as a public event and written to the outbox, and then asynchronously notified to the external system.

2. The medical image quality control process management method based on event tracing according to claim 1, characterized in that, Based on the use case orchestration, corresponding domain events are generated, and different types of domain events are subscribed to and distributed through an event bus. Based on the domain events, corresponding business processing behaviors are matched, including the following steps: Based on the case request, a DICOM archiving service is performed and a first event is published after archiving is completed, and the first event is distributed to the first subscriber; After waiting for the first subscriber to extract the sequence metadata and complete the verification, the second event is published and distributed to the second subscriber; After the second subscriber completes the conversion task scheduling for each sequence metadata, a third event is published. After the format conversion of each sequence metadata is completed concurrently based on the conversion task, a fourth or fifth event is published. The fourth or fifth event is then distributed to the third subscriber, wherein the fourth event indicates successful conversion and the fifth event indicates conversion failure.

3. The medical image quality control process management method based on event tracing according to claim 2, characterized in that, The second subscriber is also used to track the progress of the conversion task and synchronously update the record to the sequence progress detail table.

4. The medical image quality control process management method based on event tracing according to claim 3, characterized in that, The completion conditions include transformation conditions. The process involves updating the state of the aggregate root instance based on the stage where the domain event occurs and evaluating whether the completion conditions are met to determine the process state, including the following steps: Wait for the third subscriber to update the state of the aggregate root instance after each fourth or fifth event, and count the fourth or fifth events; Waiting for the third subscriber to obtain the current transfer conditions; If the transition condition requires all sequences to be successfully converted, then the transition condition is satisfied when the number of the fifth events is equal to zero after the conversion is completed, and the transition condition is not satisfied when the number of the fifth events is greater than zero. If the transition condition is that some sequences are allowed to fail and the failure ratio does not exceed a threshold, then the failure ratio is calculated based on the number of the fourth event or the fifth event, and the transition condition is satisfied when the failure ratio is not greater than the threshold, and the transition condition is not satisfied when the failure ratio is greater than the threshold. If the transfer conditions are not met, the third subscriber publishes a sixth event, which corresponds to the process state of process failure.

5. The medical image quality control process management method based on event tracing according to claim 4, characterized in that, When the transformation condition is met, the completion condition also includes a verification condition, which updates the state of the aggregate root instance based on the stage where the domain event is located and evaluates whether the completion condition is met to determine the process state. Includes the following steps; Waiting for the third subscriber to obtain the current verification conditions; If the verification condition is that AI quality verification is required, then the third subscriber performs the quality verification and publishes the seventh event after the quality verification is completed, and sends the seventh event to the fourth subscriber; If the quality verification passes, the fourth subscriber publishes an eighth event; if the quality verification fails, the fourth subscriber publishes a sixth event. The eighth event corresponds to the process status of successful process completion. If the verification condition allows for no verification, then the fourth subscriber directly generates the eighth event.

6. The medical image quality control process management method based on event tracing according to claim 5, characterized in that, It also includes the following steps: Extract the tenant field from the aggregate root instance and inherit it to the corresponding domain event; All tenants on the event bus are retrieved and tenant topics are configured. The domain event is sent to the matching tenant topic based on the tenant field. When the first subscriber, second subscriber, third subscriber, and fourth subscriber corresponding to the tenant perform the business processing behavior, they process the domain events of the tenant topic distribution they subscribed to; The event bus also includes a fifth subscriber, which is used to determine whether the tenant field in the domain event matches the tenant topic when the domain event is distributed, and to intercept the domain event and trigger an alarm if they do not match.

7. The medical image quality control process management method based on event tracing according to claim 5, characterized in that, It also includes the following steps: Determine whether there is an emergency marker in the case request. If so, the first subscriber selects a key sequence based on the examination type after extracting the sequence metadata. The conversion condition obtained by the third subscriber is that all key sequences must be successfully converted, and the verification condition obtained by the third subscriber is that all key sequences must undergo AI quality verification.

8. The medical image quality control process management method based on event tracing according to claim 1, characterized in that, The process further includes marking completed domain events as public events and writing them to the outbox based on the process status, and asynchronously notifying external systems, and also includes the following steps: Based on the business process table and event table, write the business data and event records corresponding to the public event into the outbox; Set up a background task to periodically query the outbox for unpublished events; Determine whether the public event has been successfully sent. If yes, mark the public event; otherwise, automatically retry based on the exponential backoff strategy. If the number of automatic retries exceeds the preset value, it will be marked as a dead letter record error and an alarm will be triggered.

9. The medical image quality control process management method based on event tracing according to claim 8, characterized in that, It also includes the following steps: Obtain system fault recovery information; Load all historical events of the current process into the event table; Reconstructing the aggregate root state by replaying events in chronological order.

10. A medical image quality control workflow management system based on event tracing, characterized in that, Used to implement the method as described in any one of claims 1-9.

Images