A method for standardizing faers data

Abstract

The application provides a FAERS data standardization method, which comprises the following steps: A, obtaining a FAERS data set and integrating the data set; B, performing missing value filling and deduplication operation on the integrated DEMO table; C, performing deduplication on the rest of the tables in the FAERS data set; D, performing standardization on the REAC table; E, performing standardization on the drug name in the DRUG table; and F, generating an adverse drug reaction 2*2 contingency table. The application solves the problems of data repetition, data omission and non-standard drug name in the FAERS data set, improves the proportion of drug name standardization, makes each value in the generated adverse drug reaction 2*2 contingency table more accurate, and improves the accuracy of subsequent mining of adverse drug reaction signals.

Description

Technical Field

[0001] This invention relates to a FAERS data standardization method in the fields of data mining and bioinformatics. Its main content is to improve the accuracy of subsequent mining of adverse drug reaction signals by deduplicating FAERS data and standardizing drug information, thereby improving data quality. Background Technology

[0002] Research on potential adverse drug reactions (ADRs) of currently marketed drugs primarily relies on data from voluntary reporting systems in various countries and institutions. The U.S. Food and Drug Administration's (FDA) Adverse Event Reporting System (FAERS) is a typical example of a publicly available voluntary reporting system (SRS). The FAERS database contains information on all ADR events and medication errors collected by the FDA, mainly used for post-marketing safety monitoring of drugs and biologics.

[0003] Because the self-reporting system can be used by professionals such as doctors, pharmacists, and nurses, as well as non-professionals such as patients, their families, and lawyers, the data often comes from diverse sources and lacks standardized formats. Therefore, it is crucial to standardize the data from the self-reporting system to address the issues of inaccurate, unreliable, and unreliable adverse drug reaction signals. Summary of the Invention

[0004] The purpose of this invention is to provide a reliable method for standardizing FAERS data, which is applicable to solving problems such as duplicate reporting of events, data errors, omissions, and non-standard drug names in FAERS data.

[0005] To achieve the above objectives, the present invention adopts the following technical solution:

[0006] A. Obtain the FAERS adverse drug reaction dataset. Store the DEMOyyQq.TXT and THERyyQq.TXT files from each quarter of the obtained dataset as case information data, the DRUGyyQq.TXT file as drug information data, the REACyyQq.TXT and INDIyyQq.TXT files as adverse reaction data, and the OUTCyyQq.TXT and RPSRyyQq.TXT files as other data in a locally constructed adverse drug reaction event database. Integrate the files from each quarter and name each table using the prefix of each file.

[0007] B. Normalize the data in the DEMO table integrated in step A; the process includes the following steps:

[0008] B1. Select the unique identifiers in the DEMO table used to link the files in the FASRS dataset and the relevant fields reflecting event and patient personal information. Fill the missing values ​​in the data with at most one missing value in these fields according to the event number caseid.

[0009] B2. Select the data from the two unique identifier fields primaryid and start_dt in the THER table in step A, aggregate the start_dt field according to the primaryid field, and use ' / ' as the delimiter after aggregating the start_dt field;

[0010] B3. Join the tables using the primaryid field and add the aggregated start_dt field from step B2 to the DEMO table from step B1.

[0011] B4. Group the DEMO table from step B3 according to the event number caseid field, and sort the data in the group according to the event version number caseversion field in ascending order. Keep the last row of data in the sorted group, that is, keep the latest version of each event, and complete the first deduplication of the DEMO table.

[0012] B5. Perform a second round of deduplication on the DEMO table after the first deduplication in step B4. When the data in each row is completely identical except for the three fields of primaryid, caseid, and caseversion, this data is considered duplicate data. Keep the last row of duplicate data to complete the second round of deduplication on the DEMO table.

[0013] C. Use the primaryid field to map the DEMO table (after deduplication in step B5) to the six tables DRUG, THER, REAC, INDI, OUTC, and RPSR in the FAERS dataset from step A, retaining data with the same primaryid and updating each table.

[0014] D. Standardize the REAC table using the INDI table from step C. The standardization process includes the following steps:

[0015] D1. Use the INDI table from step C to standardize the REAC table. When the content of the primaryid field in both tables is the same, and the content of the indi_pt field in the INDI table is also the same as the content of the pt field in the REAC table, delete the corresponding data in the REAC table.

[0016] D2. Obtain the MedDRA Medical Dictionary from the MedDRA website, and map the pt field in the REAC table from step D1 to the pt field in the MedDRA Medical Dictionary to complete the standardization operation of the REAC table.

[0017] E. The normalization process of the DRUG table after deduplication in step C includes the following steps:

[0018] E1. Select the field data reflecting medication information in the DRUG table after deduplication in step C, concatenate the data in these fields with ',' as the connector, and update the DRUG table.

[0019] E2. Use regular expressions to delete various special characters such as ':', '.', ', '?', ' / ', '`', '~', '!', '@', '#', '$', '%', '^', '&', '*', '-', '_', '=', and '+' from the DRUG table updated in step E1. Then split the file into 100KB files separated by '|'.

[0020] E3. Install Java 1.7 or later and configure the JAVA_HOME, CLASSPATH, and Path parameters in your computer's environment variables. Download the Medex_UIMA_1.3.8 normalization tool and extract it to your local disk, naming it MedEx_HOME, for example, D:\MedEx_UIMA_1.3.8. Save the drug information files, divided into 100KB blocks in step E2, into the input folder under the MedEx_HOME directory as the recognition source files. Store the recognition results in the output folder, separated by '|'.

[0021] E4. Execute the code "java -Xmx1024m -cp lib / *;binorg.apache.medex.Main -i input -o output -b n" in the MedEx_HOME directory. MedEx will then begin recognizing drug names from text. The default recognition automatically identifies sentence boundaries, which can cause gaps and confusion in drug names. Adding "-bn" will disable automatic sentence boundary recognition, treating each line as a separate recognition statement.

[0022] E5. Merge the output files of output by field using '|' as the delimiter, and keep the three fields Sentence_text (original drug name text), RxNorm_cui (RxNorm encoding), and Generic_name (standardized drug name) in the MedEx table;

[0023] E6. Obtain the drug vocabulary list from the DrugBank website, use the Generic_name field in the MedEx table to map the synonyms field in the DrugBank vocabulary list, and write the five fields Sentence_text, Rxcui, Generic_name, drugbankid and commonname into the drugbank_MedEx table.

[0024] E7. Since some drug information was not recognized by the Medex_UIMA_1.3.8 standardization tool and no results were returned, the data was manually queried on the DrugBank website and the drugbank_MedEx table was updated to generate a standardized dictionary of FAERS drug names.

[0025] E8. Use the Sentence_text field in the drugbank_MedEx table generated in step E7 to map the drugname field in the DRUG table in step E1. This completes the FAERS drug name standardization.

[0026] F. Generating a 2×2 contingency table of adverse drug reactions includes the following steps:

[0027] F1. Connect the two tables using the primaryid field in the Standard_drugname table in step E6 and the REAC table in step D to find the control relationship between each drug and each adverse reaction, and generate drug adverse reaction event pairs.

[0028] F2. Based on the adverse drug reaction event pairs generated in step F1, calculate the values ​​in the 2×2 contingency table of adverse drug reactions.

[0029] The FAERS data normalization method described in this invention expands the scope of data deduplication by adding a field to determine data duplication, thus solving the problem of excessive duplication rate in the data and reducing the duplication rate.

[0030] The FAERS data normalization method described in this invention increases the output of the Medex_UIMA_1.3.8 natural language processing tool by adding drug information and using regular expressions to clean up special symbols in the information, thereby improving the data normalization.

[0031] The FAERS data standardization method described in this invention improves the standardization of drug names by combining the Drug Bank drug vocabulary dictionary with the Medex_UIMA_1.3.8 natural language processing tool. Attached Figure Description

[0032] Figure 1 This is the overall flowchart of the present invention;

[0033] Figure 2 This is a schematic diagram of adverse drug reaction events. Detailed Implementation

[0034] The invention will now be described in conjunction with the accompanying drawings and specific embodiments:

[0035] Figure 1 This is a flowchart illustrating the overall process of a FAERS data normalization method according to the present invention. Figure 1 As shown, a FAERS data normalization method includes the following steps:

[0036] A. Obtaining the FAERS Adverse Drug Reaction Dataset: The FAERS dataset can be obtained from the FDA website. This dataset includes seven files: DEMOyyQq.TXT (recording patient personal information), DRUGyyQq.TXT (recording patient medication use), INDIyyQq.TXT (recording drug indications), OUTCyyQq.TXT (recording patient treatment outcomes), REACyyQq.TXT (recording adverse reactions occurring in reported events), RPSRyyQq.TXT (recording report source information), and THERyyQq.TXT (recording the start and end times of patient medication treatment). Each file uses the unique event identifier `primaryid` to connect the data in each table. These seven files are updated quarterly. There are many files and a large amount of data. Each file is stored using '$' as a separator. Before standardizing this data, the quarterly files need to be categorized and loaded into the local database according to their file prefixes. Then, the quarterly files need to be integrated according to the file prefixes and the names of each field. The integrated tables are named according to the prefixes of the original files.

[0037] B. Perform data normalization on the DEMO table integrated in step A. This mainly involves deleting duplicate reported events and retaining only the latest version of each event. Because the personnel uploading data to the self-reporting system are relatively diverse, events for the same patient may be uploaded multiple times during the upload process, resulting in data duplication or omissions. These issues constitute "noise" in adverse drug reaction mining, negatively impacting the results and rendering the discovered signals worthless for analysis.

[0038] The steps for normalizing the DEMO table in step A are as follows:

[0039] B1. Select all data from the 11 fields (primaryid, caseid, caseversion, i_f_code, event_dt, age, age_cod, sex, wt, wt_cod, and reporter_country) in the DEMO table and name the table DEMO_combined. Store data from the DEMO_combined table containing at most one missing value in the DEMO_combined table, and data containing at least two missing values ​​in the DEMO_combined_na2 table. The caseid field in each table represents the event number. Data with the same caseid indicates that the same event has been reported multiple times, so the fields reflecting patient information should also be consistent. Therefore, when the caseid field is the same, fill in the missing values ​​in the 7 fields (event_dt, age, age_cod, sex, wt, wt_cod, and reporter_country) in the DEMO_combined_na1 table. Table 1 provides specific examples before and after missing value filling. The populated data is merged with the DEMO_combined_na2 table by field, and the DEMO_combined table is updated.

[0040] Table 1 Comparison of missing value filling before and after.

[0041]

[0042] B2. Select the data from the primaryid and start_dt fields of the THER table after step A. The primaryid is a unique identifier for an event; if the primaryids are the same, they represent the same event. Therefore, aggregate the start_dt fields according to the primaryid field, using ' / ' as the delimiter after aggregation, so that start_dt fields with the same primaryid are aggregated into a single row.

[0043] B3. Connect the data in the DEMO_combined table from step B1 and the THER table from step B2 using the unique identifier primaryid, and update the DEMO_combined table. At this time, the DEMO_combined table should contain data in 12 fields, including primaryid, caseid, caseversion, i_f_code, event_dt, age, age_cod, sex, wt, wt_cod, reporter_country, and start_dt.

[0044] B4. Using the updated DEMO_combined table from step B3, the primaryid in the table consists of the event number (caseid) and the event version number (caseversion). Therefore, given the same caseid, selecting the largest primaryid effectively preserves the latest version of each event. Thus, grouping by caseid, sorting by caseversion within each group, and retaining the last record in each group preserves the latest version of each event. Updating the DEMO_combined table completes the first deduplication step.

[0045] B5. Select data from the DEMO_combined table that does not contain missing values ​​after the update in step B4, and sort them in ascending order by primaryid. If the data in the eight fields—event_dt, age, age_cod, sex, wt, wt_cod, reporter_country, and start_dt—are completely identical, treat these fields as duplicate data and retain only the data with the largest corresponding primaryid. Then update the DEMO_combined table, completing the second deduplication operation on the DEMO table.

[0046] C. Using the primaryid field in the DEMO_combined table updated in step B5, map the six tables DRUG, THER, REAC, INDI, OUTC, and RPSR of the FAERS dataset after integration in step A, retaining data with the same primaryid and updating each table.

[0047] D. Standardize the REAC table using the INDI table from step C. The standardization process includes the following steps:

[0048] D1. When the content of the primaryid field in both tables is the same, and the content of the indi_pt field in the INDI table is also the same as the content of the pt field in the REAC table, delete the corresponding data in the REAC table.

[0049] D2. Obtain the MedDRA medical dictionary from the MedDRA website. Use the pt field in the REAC table from step D1 to map the pt field in the MedDRA medical dictionary, retaining primaryid, pt, and the meddra field in the MedDRA medical dictionary, and complete the standardization operation of the REAC table.

[0050] E. The standardization process of the DRUG table after deduplication in step C includes the following steps:

[0051] E1. Select the four fields of primaryid, drugname, route, and dose_vbm from the DRUG table after deduplication in step C. Merge the data of the three fields of drugname, route, and dose_vbm by concatenating them with ',' as the concatenation operator. Name the new field drugname_combined and update the DRUG table.

[0052] E2. Use regular expressions to delete various special characters such as ':', '.', ', '?', ' / ', '`', '~', '!', '@', '#', '$', '%', '^', '&', '*', '-', '_', '=', and '+' from the DRUG table updated in step E1. Then split the file into 100KB files separated by '|'.

[0053] E3. Use the Medex_UIMA_1.3.8 natural language processing tool to perform the first normalization of the drugname_combined table split in step E2. First, install Java 1.7 or later and configure the JAVA_HOME, CLASSPATH, and Path parameters in the computer environment variables. Download the Medex_UIMA_1.3.8 normalization tool and extract it to your local disk, naming it MedEx_HOME, for example, D:\MedEx_UIMA_1.3.8. Store the drug information files divided into 100KB blocks in step E2 into the input folder under the MedEx_HOME directory as the recognition source files. Store the recognition results in the output folder, separated by '|'.

[0054] E4. Execute the code "java -Xmx1024m -cp lib / *;binorg.apache.medex.Main -i input -o output -b n" in the MedEx_HOME directory. MedEx will then begin recognizing drug names from text. The default recognition automatically identifies sentence boundaries, which can cause gaps and confusion in drug names. Adding "-bn" will disable automatic sentence boundary recognition, treating each line as a separate recognition statement.

[0055] E5. Merge the output files of output by field using '|' as the delimiter, and keep the three fields Sentence_text (original drug name text), Rxcui (RxNorm encoding), and Generic_name (standardized drug name) in the MedEx table;

[0056] E6. Obtain the drug glossary from the DrugBank website. This glossary contains four fields: synonyms, rxcui, drugbankid, and commonname. Use the Generic_name field in the MedEx table to map the synonyms field in the DrugBank glossary, and write the five fields: Sentence_text, Rxcui, Generic_name, drugbankid, and commonname into the drugbank_MedEx table.

[0057] E7. Since some drug information was not recognized by the Medex_UIMA_1.3.8 standardization tool and no results were returned, the data was manually queried on the DrugBank website. The unrecognized data was written into the Sentence_text field of the drugbank_MedEx table, and the corresponding query results were written into the three fields of Rxcui, drugbankid, and commonname. The drugbank_MedEx table was then updated to generate the FAERS drug name standardization dictionary.

[0058] E8. Using the Sentence_text field in the drugbank_MedEx table generated in step E7, map the drugname field in the DRUG table in step E1, saving the data of the four fields—primaryid, Rxcui, drugbankid, and commonname—to the Standard_drugname table, where the commonname field is the standard name of the drug. This completes the FAERS drug name standardization. Table 2 provides a specific example of the standardized name.

[0059] Table 2 Standardized data for drug names

[0060] 4204616 1399 DB01086 benzocaine 184781411 6026 DB00753 isoflurane 122950751 7824 DB00107 oxytocin 5858310 3565 DB00202 succinylcholine 107227145 16521 DB13868 adefovir 178581571 60819 DB00006 bivalirudin

[0061] F. Generate a 2×2 contingency table of adverse drug reactions, as shown in Table 3. The steps for generating the table are as follows:

[0062] F1. Connect the two tables using the primaryid field from the Standard_drugname table in step E6 and the REAC table in step D to find the correlation between each drug and each adverse reaction, generating drug adverse reaction event pairs, such as... Figure 2 As shown;

[0063] F2. Based on the adverse drug reaction event pairs generated in step F1, calculate the values ​​in the 2×2 contingency table of adverse drug reactions.

[0064] Table 3. 2×2 Contingency Table of Adverse Drug Reactions

[0065]

[0066] In the table, a represents the number of reported adverse events of the target drug; b represents the number of reported adverse events of the non-target drug; c represents the number of reported adverse events of the target drug that are not the target drug; and d represents the number of reported adverse events of the non-target drug that are not the target drug.

[0067] This invention improves the deduplication rate of files in the FAERS dataset, ensuring data uniqueness as much as possible. During the drug name standardization process, operations such as drug information extraction, splicing, and special symbol processing enhance the processing performance of the Medex_UIMA_1.3.8 natural language processing tool on this dataset.

Claims

1. A FAERS data standardization method, characterized in that: It includes the following steps: A. Obtain the FAERS adverse drug reaction dataset, and integrate the obtained DEMOyyQq.TXT, DRUGyyQq.TXT, THERyyQq.TXT, REACyyQq.TXT, INDIyyQq.TXT, OUTCyyQq.TXT, and RPSRyyQq.TXT files by quarter, import them into the local database, and name the tables in the database using the prefix of each file. B. Perform data preprocessing on the DEMO table from step A. The preprocessing includes the following steps: B1. Select the unique identifiers and relevant fields reflecting patient personal information used to connect the files in the FASRS dataset from the DEMO table, and fill in the missing values ​​for data in these fields that contain at most one missing value. B2. Aggregate the start_dt field, the unique identifier in the THER table from step A, and use ' / ' as the delimiter after aggregating the start_dt field; B3. Join using the primaryid field and add the aggregated start_dt field from step B2 to the DEMO table from step B1; B4. Group the DEMO table from step B3 according to the event number caseid field, and sort the data in the group according to the event version number caseversion field in ascending order. Keep the last row of data in the sorted group to complete the first deduplication of the DEMO table. B5. Perform a second round of deduplication on the DEMO table after the first deduplication in step B4. When the data in each row is completely identical except for the three fields of primaryid, caseid, and caseversion, retain the last row of data with duplicate data to complete the second deduplication of the DEMO table. C. Use the primaryid field to map the DEMO table (after deduplication in step B5) to the DRUG, THER, REAC, INDI, OUTC, and RPSR tables in the FAERS dataset from step A, retaining data with the same primaryid and updating each table. D. Standardize the REAC table using the INDI table from step C. The standardization process includes the following steps: D1. When the primaryid field content is the same in both tables, and the indi_pt field content of the INDI table is also the same as the pt field content of the REAC table, delete the corresponding data in the REAC table. D2. Obtain the MedDRA Medical Dictionary from the MedDRA website, and map the pt field in the REAC table from step D1 to the pt field in the MedDRA Medical Dictionary to complete the standardization operation of the REAC table; E. The standardization process of the DRUG table after deduplication in step C includes the following steps: E1. Select the field data reflecting medication information in the DRUG table after deduplication in step C, concatenate the data in these fields with ',' as the connector, and update the DRUG table; E2. Use regular expressions to delete the special symbols in the DRUG table after the update in step E1, and then split the file into 100KB files separated by '|'. E3. Install Java 1.7 or later and configure environment variables. Download the Medex_UIMA_1.3.8 normalization tool and extract it to your local disk, which you will call MedEx_HOME. Store the drug information file, which was divided into 100KB blocks in step E2, into the input folder under the MedEx_HOME directory as the recognition source file. Store the recognition results in the output folder, separated by '|'. E4, the code to execute in the MedEx_HOME directory is "java -Xmx1024m -cp lib / *;binorg.apache.medex.Main -i input -o output -bn"; E5. Merge the output files of output by field using '|' as the delimiter, and keep the three fields Sentence_text, RxNorm_cui and Generic_name in the MedEx table; E6. Obtain the drug vocabulary list from the DrugBank website, use the Generic_name field in the MedEx table to map the synonyms field in the DrugBank vocabulary list, and write the mapping result to the drugbank_MedEx table; E7. Manually query drug information that has not been processed by the Medex_UIMA_1.3.8 normalization tool on the DrugBank website, fill the query results into the drugbank_MedEx table, and generate the FAERS drug name normalization dictionary; E8. Use the dictionary generated in E7 to map the drug information in the FAERS data to complete the standardization of FAERS drug names; F. Generate a 2×2 contingency table of adverse drug reactions, as shown in Table 1, including the following steps: F1. Connect the two tables using the primaryid field in the Standard_drugname table in step E6 and the REAC table in step D to find the control relationship between each drug and each adverse reaction, and generate drug adverse reaction event pairs. F2. Based on the adverse drug reaction event pairs generated in step F1, calculate the values ​​in the 2×2 contingency table of adverse drug reactions. Table 1. Contingency Table of Adverse Drug Reactions (2×2) In the table, a represents the number of reported adverse events of the target drug; b represents the number of reported adverse events of the non-target drug; c represents the number of reported adverse events of the target drug that are not the target drug; and d represents the number of reported adverse events of the non-target drug that are not the target drug.

Images