Adverse drug reaction report data management system based on clinical treatment safety

Abstract

The invention relates to the technical field of drug safety data management, and discloses an adverse drug reaction report data management system based on clinical treatment safety. The system comprises a data integration module, an event collection module, a feature extraction module, a risk assessment module and a queue generation module which are connected in sequence. The system automatically aggregates discrete events with time proximity and same drug identification into a unified analysis unit through an event collection module; a feature extraction module constructs a structured unit symptom spectrum and extracts multi-dimensional drug use features; the risk assessment module judges the potential risk level of the unit by analyzing the correlation between the symptom spectrum evolution mode and the medication characteristics; the queue generation module generates a priority processing queue according to the risk level. According to the system, intelligent identification and risk deep mining of relevance adverse reactions are realized, and the analysis precision and early warning timeliness of drug safety monitoring are effectively improved.

Description

Technical Field

[0001] This invention relates to the field of drug safety data management technology, specifically to a drug adverse reaction reporting data management system based on clinical treatment safety. Background Technology

[0002] In current pharmacovigilance practices, healthcare information systems generally rely on spontaneous reporting systems to receive scattered reports of adverse drug reaction events. These systems typically process each report as an independent database record, focusing on the entry, storage, and statistical analysis of basic fields such as drug, symptoms, and time for a single event. Existing technologies lack effective mechanisms for identifying potential clinical connections between events when processing data, assuming all reports are statistically independent.

[0003] The shortcomings of existing technologies lie in the isolation and static nature of their analytical models. Because the system cannot effectively link multiple related events occurring within the same patient or the same drug during the treatment cycle, the understanding of adverse reactions remains at a single point in time, making it difficult to reconstruct the dynamic evolution of adverse reactions over time. Furthermore, conventional risk assessments are mostly based on the severity of symptoms reported in a single report or the incidence rate in a group, failing to conduct in-depth correlation analysis between medication characteristics and the structured evolution of the adverse reaction symptom spectrum. This makes it easy to overlook some risk patterns that depend on specific medication contexts and develop gradually, resulting in insufficient sensitivity and specificity in early warning.

[0004] The purpose of this invention is to solve the problem of automatically identifying and aggregating clinically time-related sequences of adverse reaction events from a massive amount of discrete reported events. This invention also aims to address how to integrate medication context information to intelligently analyze the dynamic changes in structured symptom profiles, thereby achieving more accurate correlational risk assessments than single-point statistics. Summary of the Invention

[0005] The purpose of this invention is to provide a data management system for reporting adverse drug reactions based on clinical treatment safety, so as to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides a data management system for reporting adverse drug reactions based on clinical treatment safety, the system comprising:

[0007] The data integration module receives and integrates multidimensional adverse drug reaction event sets from different medical sources. The multidimensional adverse drug reaction event sets include at least drug identification, event timestamp, adverse reaction symptom code, route of administration and treatment cycle information.

[0008] The event aggregation module identifies multiple reported events that are temporally close and involve the same drug identifier from a multidimensional set of adverse drug reaction events, and aggregates the reported events into one analysis unit.

[0009] The feature extraction module extracts the adverse reaction symptom codes of all reported events in each analysis unit, constructs a unit symptom spectrum based on the coding hierarchy, and obtains the drug administration route and treatment cycle information corresponding to each reported event to generate unit drug use features.

[0010] The risk assessment module determines the potential risk level of the analysis unit based on the combination of the changing patterns of the unit's symptom spectrum and the unit's medication characteristics.

[0011] The queue generation module dynamically sorts and stratifies reported events within the analysis unit based on their potential risk levels, generating an event handling queue.

[0012] Preferably, the step of identifying multiple reported events from the multidimensional adverse drug reaction event set that are temporally close and involve the same drug identifier specifically includes:

[0013] For any drug identifier, retrieve all reported events under that drug identifier along the time dimension;

[0014] Calculate the event timestamp interval between every two reported events under the drug identifier;

[0015] Set a time window threshold to merge all reported events with an event timestamp interval less than the time window threshold into a temporary event cluster;

[0016] For all reported events in each temporary event cluster, check whether their treatment cycle information overlaps or continues; if there is overlap or continuity, the temporary event cluster is identified as an analysis unit.

[0017] Preferably, the construction of the unit symptom spectrum based on the coding hierarchy specifically includes:

[0018] Obtain the adverse reaction symptom code for each reported event within the analysis unit. The adverse reaction symptom code is a hierarchical code that includes system organ classification and specific symptom terms.

[0019] Based on the classification of systemic organs, the frequency of occurrence of adverse reaction symptom codes at each level within the analysis unit is statistically analyzed;

[0020] Based on the statistical results, a tree-like hierarchical structure is constructed with the classification of system organs as the horizontal axis and the frequency of occurrence of specific symptom terms as the vertical axis. This tree-like hierarchical structure is the unit symptom spectrum.

[0021] Preferably, the generation of the unit drug use characteristics specifically involves:

[0022] Extract the drug administration route information for all reported events within the analysis unit and record the number of times different drug administration routes occur;

[0023] Extract the treatment cycle information corresponding to all reported events within the analysis unit, and calculate the shortest treatment cycle, the longest treatment cycle, and the average value of the treatment cycles;

[0024] The statistical information on the route of administration is combined with the calculation results of the treatment cycle and encapsulated into a structured data object, which is the unit drug use feature.

[0025] Preferably, the determination of the potential risk level of the analysis unit based on the combination of the changing patterns of the unit's symptom spectrum and the unit's medication characteristics specifically includes:

[0026] Traverse the tree-like hierarchical structure of the unit symptom spectrum to identify specific symptom terms that show an increasing trend in frequency over time.

[0027] The total number of specific symptom terms with an increasing trend is counted, and the severity of each term is pre-defined by combining the system organ classification to which it belongs, to calculate the dynamic symptom score.

[0028] The administration route information is read from the unit medication characteristics, and a preset risk adjustment coefficient is assigned to different administration routes; the average value of the treatment cycle is read and compared with the preset standard treatment cycle to obtain the cycle deviation index;

[0029] By integrating the dynamic symptom score, the risk adjustment coefficient, and the period deviation index, the potential risk level of the analysis unit is output through a preset rating rule mapping table.

[0030] Preferably, the dynamic sorting and stratification of reported events within the analysis unit based on potential risk levels specifically includes:

[0031] Based on the potential risk level of the analysis unit, assign it a basic ranking weight;

[0032] For each reported event within the analysis unit, an individual risk score is calculated based on the severity level of its adverse reaction symptom code, the age of the event timestamp, and the deviation of the treatment cycle from the standard value.

[0033] Multiply the basic ranking weight by the individual risk score of the reported event to obtain the comprehensive ranking score of the reported event in the queue;

[0034] The comprehensive ranking score of all reported events in all analysis units is sorted from high to low, and the reported events are automatically divided into different levels of processing channels according to the score range.

[0035] Preferably, it also includes a method for managing feedback information on reported events that have been processed, specifically:

[0036] Once a reported event within an analysis unit has been processed and clinical feedback information has been obtained, the feedback information is associated with and stored in relation to the unit's symptom spectrum and unit medication characteristics.

[0037] The feedback information is used to verify and calibrate the potential risk level determination results corresponding to the items in the rating rule mapping table that are similar to the unit symptom spectrum change pattern and unit medication characteristics of the current analysis unit.

[0038] Preferably, the step of using feedback information to verify and calibrate the potential risk level determination results corresponding to items in the rating rule mapping table that are similar to the unit symptom spectrum change pattern and unit medication characteristics of the current analysis unit specifically involves:

[0039] The confirmation results regarding the correlation between adverse reactions and medication in the feedback information will be used as verification labels;

[0040] In the rating rule mapping table, find all records that have yielded the same potential risk level as the current analysis unit;

[0041] Compare the similarity between the unit symptom spectrum change patterns and unit medication characteristics of the recorded entries and the unit symptom spectrum change patterns and unit medication characteristics of the current analysis unit;

[0042] Based on the verification tags, the rating rule logic corresponding to records with high similarity is adjusted.

[0043] Preferably, before receiving and integrating the multidimensional adverse drug reaction event set from different medical sources, a data preprocessing step is also included:

[0044] The raw data reported from different medical sources are standardized and cleaned to unify the formats of drug identification, adverse reaction symptom codes, and timestamps;

[0045] Identify and remove duplicate reports that are identical in name only;

[0046] Verify the completeness of required fields and mark and isolate records with missing key fields.

[0047] Preferably, after generating the event handling queue, the process further includes a queue update and tracing step:

[0048] Regularly scan newly received multidimensional adverse drug reaction event sets to determine whether newly reported events can be classified into existing analysis units or form new analysis units;

[0049] For new reported events that can be classified into existing analysis units, the unit symptom spectrum and unit medication characteristics of the analysis unit are immediately updated, and the potential risk level of the analysis unit and the comprehensive ranking score of all reported events within the unit are recalculated based on the updated information.

[0050] Based on the recalculation results, the sorting and hierarchical classification of relevant reported events in the event handling queue are dynamically adjusted, and a traceability log is recorded for each queue change.

[0051] Compared with the prior art, the beneficial effects of the present invention are:

[0052] By introducing dynamic rules based on temporal proximity and identical drug identifiers, the system automatically aggregates discretely reported independent events into analytical units with continuous clinical significance. This technology overcomes the limitation of traditional systems that treat each report as an isolated data point, directly constructing an event sequence reflecting the potential development process of adverse reactions. It transforms the analytical object from scattered statistical samples into complete narrative units containing temporal relationships, providing a structured data foundation for a deeper understanding of the evolution of adverse reactions. This approach enhances the clinical logic and analytical depth of data organization.

[0053] Based on the hierarchical structure of the international standard medical terminology system, the system aggregates and structures all symptom codes within the analysis unit, generating a unit symptom spectrum that accurately reflects the distribution and evolution of symptoms. Simultaneously, it integrates information on administration routes and treatment cycles to form multi-dimensional unit medication characteristics. Through algorithmic model analysis of the dynamic change patterns of the symptom spectrum and its correlation matching and weight evaluation with specific medication characteristics, it achieves a shift in risk assessment mechanisms. This technology shifts the focus of analysis from the statistics of single event attributes to the identification and interpretation of complex correlation patterns between "medication background and symptom evolution" in multi-event contexts. It can capture risk signals that depend on specific treatment contexts and develop gradually earlier and more specifically, thereby improving the accuracy of risk warnings and their clinical guidance value. Attached Figure Description

[0054] Figure 1 This is a sequence diagram of the adverse drug reaction reporting data management system based on clinical treatment safety as described in this invention;

[0055] Figure 2 A flowchart for creating an analysis unit for the event aggregation module;

[0056] Figure 3 A flowchart for constructing unit symptom spectra for the feature extraction module;

[0057] Figure 4 A mapping diagram of the overall ranking score and treatment channels for reported adverse drug reaction events;

[0058] Figure 5 A bar chart comparing the number of adverse reaction events for different drugs. Detailed Implementation

[0059] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0060] Please see Figure 1 This invention provides a data management system for reporting adverse drug reactions based on clinical treatment safety. The system includes: a data integration module responsible for receiving multidimensional adverse drug reaction event sets from different medical sources such as hospital information systems, pharmacy management systems, and clinical research databases. Data entries in this set include at least drug identification, event timestamps, adverse reaction symptom codes, routes of administration, and treatment cycles. An event aggregation module identifies multiple reported events that are temporally adjacent and involve the same drug identification from the integrated multidimensional adverse drug reaction event set, and aggregates these related reported events into an analysis unit for overall analysis. A feature extraction module extracts the adverse reaction symptom codes of all reported events within each analysis unit, and constructs a unit symptom spectrum reflecting the overall symptom distribution based on the hierarchical structure of the codes. Simultaneously, this module obtains the route of administration and treatment cycle information corresponding to each reported event, and generates unit medication features characterizing the medication pattern after statistical analysis. A risk assessment module, based on the variation patterns of the constructed unit symptom spectrum and the combination of unit medication features, determines the level of potential safety risk represented by the analysis unit using preset rules or models. The queue generation module dynamically sorts and stratifies the specific reported events belonging to each analysis unit based on the potential risk level determined by the risk assessment module, and finally generates an event handling queue with clear priorities and hierarchical structure to guide subsequent clinical review and intervention.

[0061] In one embodiment of the present invention, see [reference] Figure 2The data preprocessing step receives raw reports from different medical institutions. Some institutions use the brand name "Levofloxacin" and others use the generic name "Levofloxacin Hydrochloride Injection." The data integration module performs standardized cleaning, mapping all these identifiers to the international nonproprietary drug name "Levofloxacin." For adverse reaction symptom coding, records from Hospital A use "R10.9" to represent abdominal pain, while records from Hospital B use the text description "abdominal pain." The data integration module, based on a medical standard terminology dictionary, standardizes both the text description "abdominal pain" and the code "R10.9" to the same hierarchical coding system, using the code "10017995." For event timestamps, the raw data contains multiple formats such as "2023-05-10 14:30" and "2023 / 05 / 10 02:30PM." The data integration module converts these to the ISO8601 standard format "2023-05-10T14:30:00." In some embodiments, after standardized cleaning, the system identifies and removes duplicate reports that are identical in name only. In a specific implementation, two reported records both contain the drug identifier "Levofloxacin", the event timestamp "2023-05-10T14:30:00", the adverse reaction symptom code "10017995", the route of administration "intravenous injection", and the treatment period information "2023-05-09 to 2023-05-10". The system determines these two records to be duplicates and retains only one for subsequent analysis. The data integration module verifies the completeness of required fields and marks and isolates records with missing key fields. In a specific implementation, one reported record contains the drug identifier "Levofloxacin" and the adverse reaction symptom code "10017995", but the event timestamp field is empty; another reported record has an empty treatment period information field. The data integration module marks these records as "missing key fields" and does not pass them to the event collection module.

[0062] Understandably, the event set after data preprocessing achieves a unified standard in terms of drug identification, adverse reaction symptom coding, and timestamp format, and eliminates duplicate and incomplete records, providing a consistent data foundation for subsequent analysis. The event aggregation module retrieves all reported events under any given drug identification along the time dimension.

[0063] For all reported events in each temporary event cluster, the event aggregation module checks whether their treatment cycle information overlaps or continues. In specific implementation, temporary event cluster C1 contains four reported events with treatment cycle information of "2023-05-08 to 2023-05-10", "2023-05-09 to 2023-05-11", "2023-05-10 to 2023-05-12", and "2023-05-11 to 2023-05-12". These treatment cycles overlap in time, and the event aggregation module identifies temporary event cluster C1 as an analysis unit. The reported event with timestamp T5 has treatment cycle information of "2023-06-01 to 2023-06-03", which does not overlap or continue with the treatment cycles of any events in temporary event cluster C1, and therefore is not included in the same analysis unit. It can be understood that the time window threshold... The settings can be adjusted based on the pharmacokinetic characteristics of the drug or clinical monitoring needs, and are used to define the specific range of time proximity. Verification of treatment cycle information excludes events with similar timestamps but actually representing different treatment processes, ensuring the logical rigor of the aggregation.

[0064] In practical implementation, the time window threshold The assignment can be derived based on the drug's half-life parameter. One possible derivation relationship is as follows:

[0065]

[0066] in: Represents the time window threshold. This represents the average half-life of a drug in the human body. It is a preset multiplier. Multiplier The numerical range is typically between 3 and 5. For drugs with short half-lives, the time window threshold... Correspondingly shortened, for drugs with long half-lives, the time window threshold. Corresponding extension. Multiplier. The specific value is configured by the system administrator based on regulatory requirements or clinical experience.

[0067] In one embodiment of the present invention, see [reference] Figure 3The feature extraction module operates on an analysis unit confirmed by the event aggregation module. This unit contains four reported events involving the drug identifier "Levofloxacin". The feature extraction module obtains the adverse reaction symptom code for each reported event within the analysis unit. Each adverse reaction symptom code is a hierarchical code containing system organ classification and specific symptom terminology. For example, the adverse reaction symptom code for the first reported event is "10017995 (Gastrointestinal Disease - Abdominal Pain)", the second is "10017996 (Gastrointestinal Disease - Nausea)", the third is "10017996 (Gastrointestinal Disease - Nausea)", and the fourth is "10037287 (Skin and Subcutaneous Tissue Diseases - Rash)". The feature extraction module statistically analyzes the frequency of occurrence of each level of adverse reaction symptom code within the analysis unit, organized by system organ classification. In practice, for the system organ classification "Gastrointestinal Diseases," the specific symptom term "abdominal pain" appeared once, and the specific symptom term "nausea" appeared twice; for the system organ classification "Skin and Subcutaneous Tissue Diseases," the specific symptom term "rash" appeared once. Based on the statistical results, the feature extraction module constructs a tree-like hierarchical structure with the system organ classification as the horizontal axis and the frequency of specific symptom terms as the vertical axis. This tree-like hierarchical structure is the unit symptom spectrum. In practice, the root node of the unit symptom spectrum is the drug identifier "Levofloxacin," the first-level child nodes are the system organ classifications "Gastrointestinal Diseases" and "Skin and Subcutaneous Tissue Diseases," and the second-level child nodes are the specific symptom terms "abdominal pain" (frequency: 1) and "nausea" (frequency: 2) belonging to "Gastrointestinal Diseases," and the specific symptom term "rash" (frequency: 1) belonging to "Skin and Subcutaneous Tissue Diseases." The unit symptom spectrum visually presents the distribution of adverse reactions in this tree-like hierarchical structure.

[0068] It is understandable that the construction of the unit symptom spectrum relies on a standardized, hierarchical adverse reaction symptom coding system. In some embodiments, the adverse reaction symptom coding adopts an international medical terminology set, with system organ classification corresponding to high-level concepts and specific symptom terms corresponding to low-level concepts. The feature extraction module aggregates scattered symptom reports into a statistically significant spectrum by parsing the coding hierarchy and counting frequencies. In specific implementations, the feature extraction module simultaneously generates unit medication features for the analysis unit. The feature extraction module extracts the administration route information for all reported events within the analysis unit and records the frequency of different administration routes. For example, in four reported events, three were administered via "intravenous injection" and one via "oral administration." The feature extraction module records "intravenous injection" as occurring 3 times and "oral administration" as occurring 1 time. The feature extraction module also extracts the treatment cycle information corresponding to all reported events within the analysis unit, calculating the shortest treatment cycle, the longest treatment cycle, and the average treatment cycle. For example, the treatment cycles for four reported events were 5 days, 7 days, 4 days, and 6 days, respectively. The feature extraction module calculated that the shortest treatment cycle was 4 days, the longest was 7 days, and the average treatment cycle was (5+7+4+6) / 4=5.5 days. The feature extraction module combines the statistical information of the route of administration with the calculated treatment cycle results and encapsulates them into a structured data object. This structured data object is the unit medication feature.

[0069] It is understandable that the unit symptom spectrum and unit medication characteristics together constitute a complete feature profile of an analysis unit. In some embodiments, in order to more accurately measure the importance of different symptoms in subsequent risk assessment, the feature extraction module, when constructing the unit symptom spectrum, not only counts the frequency but also calculates a weight value for each specific symptom term node in the tree-like hierarchical structure. One optional weight calculation method considers the frequency of symptom occurrence within the unit and the preset basic weight of its corresponding organ system classification. The weight calculation relationship is expressed as:

[0070]

[0071] in: This represents a system organ classification. Specific symptom terminology Weights in the unit symptom spectrum Terms representing specific symptoms Frequency of occurrence within this analysis unit This represents the total number of events reported within this analysis unit. Representative system organ classification The preset severity coefficient. The preset severity coefficient for system organ classification. Based on pre-defined clinical consensus, such as the classification of "cardiac organ diseases". Values ​​higher than those classified as "Gastrointestinal Diseases" Value. Weight of specific symptom terms. This will be recorded in the corresponding node attributes of the unit symptom spectrum tree hierarchy. In specific implementation, for the system organ classification "gastrointestinal system diseases", a severity coefficient is preset. The frequency of the specific symptom term "nausea" was 1.0. The total number of events reported within the analysis unit is 2. If the weight is 4, then the specific symptom term "nausea" has a weight of 4. The calculation is (2 / 4)*1.0=0.5.

[0072] In one embodiment of the present invention, the risk assessment module receives unit symptom spectra and unit medication characteristics from the feature extraction module, and performs a potential risk level determination on an analysis unit containing four reported events ordered by time series, involving the drug identifier "Levofloxacin". The risk assessment module traverses the tree-like hierarchical structure of the unit symptom spectra to identify specific symptom terms whose frequency of occurrence in the time series shows an increasing trend. In a specific implementation, the unit symptom spectra shows that the specific symptom term "nausea" appears in the four reported events as follows: the first reported event did not report "nausea", the second and third reported events reported "nausea", and the fourth reported event also reported "nausea". From the time series, the reporting frequency of "nausea" shows an increasing trend from 0 to 1 and then to 2. The specific symptom term "rash" only appears in the fourth reported event and does not constitute an increasing trend across multiple time points. The risk assessment module counts the total number of specific symptom terms with an increasing trend, and calculates a dynamic symptom score by combining the severity preset weights of their respective system organ classifications. In practice, "nausea" was identified as a specific symptom term with an increasing trend, totaling 1. The severity weight of the organ system classification "gastrointestinal diseases" to which "nausea" belongs was preset to 1.0. Symptom dynamic scoring... The calculation relationship is expressed as follows:

[0073]

[0074] in: Represents dynamic symptom scores. This represents the total number of specific symptom terms that show an increasing trend. Representing the An increasing gradient of specific symptom terms with an increasing trend. Representing the The systemic organ classification to which specific symptom terms belong The severity is preset with weights. Increasing gradient. The numerical rule is that if the frequency increases from 0 to 1, then The value is 1; if the number of times increases from 0 to 2 or more, or from 1 to 2, then The frequency is 2. In practice, for the specific symptom term "nausea," the frequency increases from 0 to 2 times, in an incremental gradient. The severity of the organ system to which it belongs is preset to a value of 2. The score is 1.0, therefore the dynamic symptom score is... The value is 2 * 1.0 = 2.0.

[0075] The risk assessment module reads the route of administration information from the unit's drug use characteristics and assigns preset risk adjustment coefficients to different routes of administration. In the specific implementation, the unit's drug use characteristics show that the route of administration "intravenous injection" appears 3 times and "oral administration" appears once. The preset risk adjustment coefficient rules are: a risk adjustment coefficient of 1.2 for the "intravenous injection" route and a risk adjustment coefficient of 1.0 for the "oral administration" route. The module assigns coefficients based on the primary route of administration; since "intravenous injection" is the primary route of administration in the current analysis unit, a risk adjustment coefficient is used. The risk assessment module reads the average treatment cycle and compares it with the preset standard treatment cycle to obtain a cycle deviation index. In specific implementation, the average treatment cycle in the unit drug use characteristic is 5.5 days, and the preset standard treatment cycle for "Levofloxacin" is... The period is 7 days. Cycle deviation index. The calculation is the absolute value of the difference between the average treatment cycle and the standard treatment cycle. sky.

[0076] It is understandable that the calculation of dynamic symptom scores, risk adjustment coefficients, and periodic deviation indicators transforms the dynamic change patterns of the unit symptom spectrum and the specific combination of unit medication characteristics into quantifiable parameters. The risk assessment module integrates dynamic symptom scores, risk adjustment coefficients, and periodic deviation indicators, and outputs the potential risk level of the analysis unit through a preset rating rule mapping table. In some embodiments, this integration is achieved through a comprehensive scoring function. One optional comprehensive scoring function is:

[0077]

[0078] in: It is a comprehensive score. This is the weighting coefficient for the period deviation. The rating rule mapping table defines the comprehensive score. The correspondence between Z and potential risk levels is defined, for example, Z corresponds to "low risk" in the [0,3) interval, "medium risk" in the [3,6) interval, and "high risk" in the [6,+∞) interval. In practical implementation, a weighting coefficient is set for the periodic deviation. The comprehensive score was calculated. According to the rating rule mapping table, the comprehensive score Z is 2.7, falling within the [0,3) interval. Therefore, the potential risk level of this analysis unit is output as "low risk". It is understood that the specific interval divisions and weighting coefficients of the rating rule mapping table can be configured and adjusted based on historical data analysis and expert knowledge. In some embodiments, the rating rule mapping table does not use a single comprehensive score, but instead uses dynamic symptom scores, risk adjustment coefficients, and periodic deviation indicators as joint inputs, directly mapping the potential risk level through a rule-based or decision tree-based logical judgment module.

[0079] In one embodiment of the present invention, the queue generation module dynamically sorts and stratifies the reported events within an analysis unit based on the potential risk level output by the risk assessment module. This analysis unit has a drug identifier of "DrugX", a potential risk level determined to be "medium risk", and contains three reported events, identified as event A, event B, and event C. The queue generation module assigns a basic ranking weight to the analysis unit based on its potential risk level. In a specific implementation, the preset mapping relationship between potential risk level and basic ranking weight is: "low risk" corresponds to weight 1.0, "medium risk" corresponds to weight 1.5, and "high risk" corresponds to weight 2.0. Therefore, the basic ranking weight of the current analysis unit... For each reported event within the analysis unit, the queue generation module calculates an individual risk score for each reported event by combining the preset severity level of its adverse reaction symptom code, the freshness of the event timestamp, and the deviation of the treatment cycle from the standard value. In practice, the preset severity level of the adverse reaction symptom code is predefined according to the coding system; for example, level 1 is mild, level 2 is moderate, and level 3 is severe. The freshness of the event timestamp is represented by the difference in the number of days between the event occurrence date and the current date; the smaller the difference, the more recent the event. The deviation of the treatment cycle from the standard value is represented by the absolute difference between the actual number of days in the treatment cycle and the standard treatment cycle number of days for the drug. Refer to Table 1 for the calculation of the individual risk score for reported events.

[0080] Table 1: Calculation Table of Individual Risk Scores for Reported Events

[0081] Event ID Severity level Time and age (sky) Period deviation (sky) Individual risk score Calculation process Individual risk score Event A 3 5 2 1.86 Event B 2 10 1 1.23 Event C 1 2 3 1.55

[0082] In practice, individual risk scores The calculation formula is:

[0083]

[0084] in: The individual risk score representing the reported incident. The pre-defined severity level represents the coded adverse reaction symptoms. Represents the age or newness of the event's timestamp. This represents the extent to which the treatment cycle deviates from the standard value. It is a weighting factor for the severity level. It is a weighting coefficient for the degree of time freshness. This is the weighting coefficient for the period deviation amplitude. In specific implementation, the weighting coefficient is preset to... , , It's understandable, the degree of time... Using the reciprocal form Involved in calculations to reflect the newer the event ( The smaller the value, the greater its contribution to the individual's risk score. For event A, , , Calculated The queue generation module will use the basic sorting weights. Individual risk scores of reported events Multiply by the sum to obtain the overall ranking score of the reported event in the queue. ,Right now In practical implementation, the comprehensive ranking score of event A... The overall ranking score of event B The overall ranking score of event C .

[0085] The queue generation module sorts all reported events within all analysis units according to their comprehensive ranking scores from highest to lowest, and automatically assigns them to different levels of handling channels based on the score range. In some embodiments, the preset correspondence between comprehensive ranking score ranges and handling channels is as follows: scores above 2.5 are assigned to the "priority handling channel," scores between 1.5 and 2.5 are assigned to the "regular handling channel," and scores below 1.5 are assigned to the "deferred handling channel." In a specific implementation, event A has a comprehensive ranking score of 2.79, which is above 2.5, and is assigned to the "priority handling channel"; event C has a comprehensive ranking score of 2.325, which is between 1.5 and 2.5, and is assigned to the "regular handling channel"; event B has a comprehensive ranking score of 1.845, which is between 1.5 and 2.5, and is also assigned to the "regular handling channel." The queue generation module generates an initial event handling queue based on this rule. It can be understood that the threshold of the comprehensive ranking score range can be adjusted according to actual handling resources and regulatory requirements.

[0086] The system also includes a queue update and tracing step. This step periodically scans newly received multidimensional adverse drug reaction event sets to determine whether newly reported events can be categorized into existing analysis units or form new analysis units. In practice, the system performs a scan every 24 hours. A newly received reported event involving the drug identifier "DrugX" is identified as event D. If the time interval between the event's timestamp and the most recent event in the existing analysis unit is less than a preset threshold, and there is overlap in treatment cycle information, the system determines that event D can be categorized into the existing "DrugX" analysis unit. For newly reported events that can be categorized into an existing analysis unit, the system immediately updates the unit's symptom spectrum and unit medication characteristics, and recalculates the potential risk level of the analysis unit and the comprehensive ranking score of all reported events within the unit based on the updated information. In practice, after including event D, the frequency of "rash" symptoms in the unit's symptom spectrum increases, and the average treatment cycle in the unit's medication characteristics is updated to 5.8 days. The risk assessment module recalculates based on the updated unit symptom spectrum and unit medication characteristics, adjusting the potential risk level from "medium risk" to "high risk," and the basic ranking weight. The corresponding update is version 2.0. The queue generation module then recalculates the individual risk score and overall ranking score for all reported events within the analysis unit.

[0087] Based on the recalculation results, the system dynamically adjusts the sorting and hierarchical classification of relevant reported events in the event handling queue. In some embodiments, after recalculation, the comprehensive ranking score of event A becomes 3.12, event B becomes 1.64, event C becomes 2.60, and event D initially calculates to 2.90. According to the same score range rules, events A, C, and D are assigned to the "priority handling channel," and event B is assigned to the "regular handling channel," updating the queue sorting order to event A, event D, event C, event B. It is understood that the addition of new events may change the overall risk characteristics of the analysis unit, thereby affecting the handling priority of all relevant events in the queue. Simultaneously, the system records a traceability log for each queue change. In specific implementations, the traceability log records the change time, the ID of the new event triggering the change, the ID of the affected analysis unit, a snapshot of the queue state before recalculation, a snapshot of the queue state after recalculation, and the parameter version used in the calculation. Optionally, the traceability log is stored in a structured format in the system log database for auditing and review purposes. The queue update and traceability steps ensure that the event handling queue can dynamically evolve in response to new data, maintaining its timeliness and accuracy.

[0088] See Figure 4This is a mapping chart of the comprehensive ranking score and treatment channels for reported adverse drug reaction events. It displays the risk score of different reported events and their corresponding treatment priorities. The comprehensive ranking score directly determines the treatment channel. Event A is marked as priority treatment because its score exceeds the threshold, while events B and C are classified into the regular channel. This visually distinguishes between high-risk events (Event A) and regular events, ensuring that high-risk events receive priority responses and improving the timeliness of drug safety management. Transforming abstract risk scores into visualized channel levels makes it easy for non-professionals to quickly understand the treatment priorities of events. It provides a quantitative basis for the handling process of adverse drug reaction events, reduces the differences in human decision-making, and ensures the standardization and consistency of management.

[0089] In one embodiment of the present invention, the system manages feedback information for reported events that have been processed. An analysis unit involving the drug identifier "Drug Y" contains three reported events. The unit's symptom spectrum shows the main symptom as "abnormal liver function (code: 10022111)," and the unit's medication characteristics show the main route of administration as "intravenous injection," with an average treatment period of 8 days. The potential risk level of the analysis unit is determined to be "high risk." After review and processing in the event processing queue, clinical feedback information is obtained. When a reported event within an analysis unit is processed and clinical feedback information is obtained, the system associates and stores the feedback information with the unit's symptom spectrum and medication characteristics. In specific implementations, the clinical feedback information is recorded using structured fields, including a "Relevance Evaluation" field with values ​​of "Confirmed Relevant," "Possibly Relevant," "Possibly Irrelevant," "Irrelevant," or "Cannot Evaluate." For the "Drug Y" analysis unit, the relevance evaluation given by clinical experts after review is "Confirmed Relevant." The system establishes an index association between this feedback information and the identifier of the analysis unit, the data snapshot of the unit's symptom spectrum, and the data snapshot of the unit's medication characteristics, and stores it in the feedback information knowledge base.

[0090] The system uses feedback information to verify and calibrate the potential risk level determination results corresponding to entries in the rating rule mapping table that are similar to the unit symptom spectrum change patterns and unit medication characteristics of the current analysis unit. Specifically, during calibration, the system uses the confirmation results regarding the correlation between adverse reactions and medication in the feedback information as verification labels. In practice, the correlation evaluation "confirmed correlation" in the feedback information obtained for the "Drug Y" analysis unit serves as the verification label. This label indicates that the characteristic pattern of the current analysis unit has been clinically proven to have a clear risk correlation. The system searches the rating rule mapping table for all records that have previously yielded the same potential risk level as the current analysis unit. In practice, the system queries the rating rule mapping table for all historical determination records with a potential risk level of "high risk." These records contain unit symptom spectrum change patterns and unit medication characteristic data used by other analysis units in the past when making determinations.

[0091] The system compares the unit symptom spectrum change patterns and unit medication characteristics of recorded entries with the unit symptom spectrum change patterns and unit medication characteristics of the currently analyzed unit, calculating the similarity. In some embodiments, the similarity calculation encompasses the similarity of symptom spectrum and the similarity of medication characteristics. An optional comprehensive similarity calculation formula is as follows:

[0092]

[0093] in: Represents overall similarity. The similarity of the patterns of change in the symptom spectrum of the representative unit. The similarity of the characteristics of the representative unit medication. It is a weighting coefficient between 0 and 1, used to balance the contributions of the two parts of similarity. Similarity of unit symptom spectrum change patterns. This can be obtained by calculating the cosine similarity or Jaccard similarity coefficient between two symptom spectrum vectors. Similarity of unit drug features. The similarity can be calculated by comparing the similarity of the distribution vectors of the administration route and the closeness of the average treatment cycle. In specific implementation, the system calculates the comprehensive similarity between the "Drug Y" analysis unit and each "high-risk" historical record entry in the rating rule mapping table. This is understandable; considering the overall similarity... The closer the value is to 1, the more similar the feature patterns of the two analysis units are.

[0094] The system adjusts the rating rules for records with high similarity based on verification tags. In practice, a similarity threshold is set. ,For example Regarding the overall similarity Greater than the threshold The system considers historical entries to be highly similar to validated "Drug Y" analysis units. Since the validation label for "Drug Y" analysis units is "confirmed relevance," this provides positive validation for the "high-risk" determination. Adjustments the system can make include enhancing or solidifying the weights or confidence levels of the rules that generate the "high-risk" determination for these similar entries. In some embodiments, the rating rule mapping table is based on a set of weighted rules or a trainable model; adjustments are made by increasing the weights of the triggering conditions of relevant rules, or by supplementing the model with a training sample labeled "high-risk - confirmed relevance" to fine-tune the model parameters. Regarding the overall similarity... Below the threshold The system will not adjust the historical records for now. It is understandable that if the verification label is "irrelevant" or "potentially irrelevant," the adjustment direction for highly similar historical records will be reversed, potentially weakening the weight of the relevant judgment logic or the trigger threshold.

[0095] Optionally, the calibration process does not immediately modify the rating rule mapping table used in the production environment. Instead, it generates a set of rule adjustment suggestions, which are then reviewed by regulators before a decision is made on whether and how the adjustments will be applied to the rating rule mapping table. The system logs each verification and calibration operation, including the target analysis unit, feedback tags used for verification, identifiers of historical records being compared, calculated similarity values, and the generated adjustment suggestions.

[0096] See Figure 5 This is a bar chart comparing the number of adverse reaction events for different drugs, showing the differences in the frequency of adverse reaction reporting for each drug. Drug Y has a significantly higher number of adverse reaction events than other drugs, making it the highest-risk drug currently. Drugs B, D, and E also have a high number of events, classifying them as high-risk drugs. The significant differences in the number of adverse reaction reports among different drugs reflect distinct differences in their safety characteristics. Drug Y is clearly the primary target for supervision, requiring priority in adverse reaction tracing and medication compliance verification; more monitoring resources should be allocated to high-risk drugs (B, D, and E). Drugs with a high number of events can trigger targeted risk warning mechanisms, reducing the potential harm of adverse events. This can provide a reference for clinical drug use and assist pharmacy departments in optimizing drug procurement and inventory management.

[0097] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0098] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A data management system for reporting adverse drug reactions based on clinical treatment safety, characterized in that, include: The data integration module receives and integrates multidimensional adverse drug reaction event sets from different medical sources. The multidimensional adverse drug reaction event sets include at least drug identification, event timestamp, adverse reaction symptom code, route of administration and treatment cycle information. The event aggregation module identifies multiple reported events that are temporally close and involve the same drug identifier from a multidimensional set of adverse drug reaction events, and aggregates the reported events into one analysis unit. The feature extraction module extracts the adverse reaction symptom codes of all reported events in each analysis unit, constructs a unit symptom spectrum based on the coding hierarchy, and obtains the drug administration route and treatment cycle information corresponding to each reported event to generate unit drug use features. The risk assessment module determines the potential risk level of the analysis unit based on the combination of the changing patterns of the unit's symptom spectrum and the unit's medication characteristics. The queue generation module dynamically sorts and stratifies reported events within the analysis unit based on their potential risk levels, generating an event handling queue.

2. The adverse drug reaction reporting data management system based on clinical treatment safety according to claim 1, characterized in that, The identification of multiple reported events that are temporally close and involve the same drug identifier from a multidimensional adverse drug reaction event set specifically includes: For any drug identifier, retrieve all reported events under that drug identifier along the time dimension; Calculate the event timestamp interval between every two reported events under the drug identifier; Set a time window threshold to merge all reported events with an event timestamp interval less than the time window threshold into a temporary event cluster; For all reported events in each temporary event cluster, check whether their treatment cycle information overlaps or continues; if there is overlap or continuity, the temporary event cluster is identified as an analysis unit.

3. The adverse drug reaction reporting data management system based on clinical treatment safety according to claim 2, characterized in that, The construction of the unit symptom spectrum based on the coding hierarchy is specifically as follows: Obtain the adverse reaction symptom code for each reported event within the analysis unit. The adverse reaction symptom code is a hierarchical code that includes system organ classification and specific symptom terms. Based on the classification of systemic organs, the frequency of occurrence of adverse reaction symptom codes at each level within the analysis unit is statistically analyzed; Based on the statistical results, a tree-like hierarchical structure is constructed with the classification of system organs as the horizontal axis and the frequency of occurrence of specific symptom terms as the vertical axis. This tree-like hierarchical structure is the unit symptom spectrum.

4. The adverse drug reaction reporting data management system based on clinical treatment safety according to claim 3, characterized in that, The generation of the unit medication characteristics is specifically as follows: Extract the drug administration route information for all reported events within the analysis unit and record the number of times different drug administration routes occur; Extract the treatment cycle information corresponding to all reported events within the analysis unit, and calculate the shortest treatment cycle, the longest treatment cycle, and the average value of the treatment cycles; The statistical information on the route of administration is combined with the calculation results of the treatment cycle and encapsulated into a structured data object, which is the unit drug use feature.

5. The adverse drug reaction reporting data management system based on clinical treatment safety according to claim 4, characterized in that, The determination of the potential risk level of the analysis unit based on the combination of the changing patterns of the unit's symptom spectrum and the unit's medication characteristics specifically includes: Traverse the tree-like hierarchical structure of the unit symptom spectrum to identify specific symptom terms that show an increasing trend in frequency over time. The total number of specific symptom terms with an increasing trend is counted, and the severity of each term is pre-defined by combining the system organ classification to which it belongs, to calculate the dynamic symptom score. The administration route information is read from the unit drug characteristics, and a preset risk adjustment coefficient is assigned to different administration routes; the average value of the treatment cycle is read and compared with the preset standard treatment cycle to obtain the cycle deviation index; By integrating the dynamic symptom score, the risk adjustment coefficient, and the period deviation index, the potential risk level of the analysis unit is output through a preset rating rule mapping table.

6. The adverse drug reaction reporting data management system based on clinical treatment safety according to claim 5, characterized in that, The dynamic sorting and stratification of reported events within the analysis unit based on potential risk levels specifically includes: Based on the potential risk level of the analysis unit, assign it a basic ranking weight; For each reported event within the analysis unit, an individual risk score is calculated based on the severity level of its adverse reaction symptom code, the age of the event timestamp, and the deviation of the treatment cycle from the standard value. Multiply the basic ranking weight by the individual risk score of the reported event to obtain the comprehensive ranking score of the reported event in the queue; The comprehensive ranking score of all reported events in all analysis units is sorted from high to low, and the reported events are automatically divided into different levels of processing channels according to the score range.

7. The adverse drug reaction reporting data management system based on clinical treatment safety according to claim 6, characterized in that, It also includes methods for managing feedback information on reported incidents that have been processed, specifically: Once a reported event within an analysis unit has been processed and clinical feedback information has been obtained, the feedback information is associated with and stored in relation to the unit's symptom spectrum and unit medication characteristics. The feedback information is used to verify and calibrate the potential risk level determination results corresponding to the items in the rating rule mapping table that are similar to the unit symptom spectrum change pattern and unit medication characteristics of the current analysis unit.

8. The adverse drug reaction reporting data management system based on clinical treatment safety according to claim 7, characterized in that, The process of using feedback information to verify and calibrate the potential risk level determination results corresponding to entries in the rating rule mapping table that are similar to the unit symptom spectrum change pattern and unit medication characteristics of the current analysis unit is specifically as follows: The confirmation results regarding the correlation between adverse reactions and medication in the feedback information will be used as verification labels; In the rating rule mapping table, find all records that have yielded the same potential risk level as the current analysis unit; Compare the similarity between the unit symptom spectrum change patterns and unit medication characteristics of the recorded entries and the unit symptom spectrum change patterns and unit medication characteristics of the current analysis unit; Based on the verification tags, the rating rule logic corresponding to records with high similarity is adjusted.

9. The adverse drug reaction reporting data management system based on clinical treatment safety according to claim 1, characterized in that, Before receiving and integrating the multidimensional adverse drug reaction event set from different medical sources, a data preprocessing step is also included: The raw data reported from different medical sources are standardized and cleaned to unify the formats of drug identification, adverse reaction symptom codes, and timestamps; Identify and remove duplicate reports that are identical in name only; Verify the completeness of required fields and mark and isolate records with missing key fields.

10. The adverse drug reaction reporting data management system based on clinical treatment safety according to claim 1, characterized in that, After generating the event handling queue, the process also includes queue updating and tracing steps: Regularly scan newly received multidimensional adverse drug reaction event sets to determine whether newly reported events can be classified into existing analysis units or form new analysis units; For new reported events that can be classified into existing analysis units, the unit symptom spectrum and unit medication characteristics of the analysis unit are immediately updated, and the potential risk level of the analysis unit and the comprehensive ranking score of all reported events within the unit are recalculated based on the updated information. Based on the recalculation results, the sorting and hierarchical classification of relevant reported events in the event handling queue are dynamically adjusted, and a traceability log is recorded for each queue change.

Images