Saturday, June 2, 2012

Review on Adverse Event Reporting System


Review on Adverse Event Reporting System

by 
 Developed by: Sarmistha Mahapatra
Reviewed by: Lanka Srinivas

Introduction

Adverse event reporting system is basically a database that is designed to support the US FDA’s post marketing surveillance program. This database contains a pool of information on adverse events and medication reports that are submitted to the FDA. The FDA uses AERS to monitor for new adverse events and medication errors that might occur with these marketed products. The structure of AERS is in compliance with the international safety reporting guidance (ICH E2B2) issued by the International Conference on Harmonization while the Adverse events in AERS are coded according to the terms in the Medical Dictionary for Regulatory Activities terminology (MedDRA).

Adverse event reporting in US though is not mandatory, however healthcare professionals, pharmaceutical companies and consumers may report the adverse events directly to the FDA. The MedWatch site provides information about voluntary and mandatory reporting. This reports received by the FDA are then evaluated by clinical reviewers in the centre for drug evaluation and Research (CDER) and the center for biologics Evaluation and Research (CBER) , which are used to monitor the product’s safety profile. On the basis of these evaluation , FDA may take regulatory action(s) to improve the product’s safety profile by either updating a product’s labeling information, restricting the use of the drug, communicating new safety information to the public, or, in rare cases, removing a product from the market , thereby ensuring the safety of the people.

The main purpose of setting up an adverse event reporting system is to refine the drug having least toxicity, as the increased number of reports would lead to analysis of the product characteristics which would indirectly help us to improve the product more thus ensuring the total safety to people. Besides this, it would also create an increased awareness among people about the product they are consuming.
Adverse Event Reporting system Requirements:

The three basic and quite essential parameters for maintenance of any ADR system are:
Collection: This involves the collection of adverse events occurring worldwide through various reliable sources such as marketing authorization holders, healthcare professionals, consumers, international/public bodies, journals, published and updated literature, etc.

Analysis and Classification: 

All the collected information need to be analyzed and classified appropriately.
Circulation: This analyzed information now has to be circulated among the all the health care practitioners, Marketing authorization Holders ,for creating awareness about the benefit/risk characteristic of the product.
Contents of Adverse Event report:
While reporting an adverse event to any databases or forms , the adverse event report should cover these four factors:- Patient Drug Adverse event. Composer/reporter of the report.

Types of Reports:

Learning systems
Reporting to learning systems is usually voluntary, and typically spans a wider scope of reportable events than the defined set of events typically required by a mandatory system. Rather than assure a minimum standard of care, learning systems are designed to foster continuous improvements in care delivery by identifying themes, reducing variation, facilitating the sharing of best practices, and stimulating system-wide improvements. Following careful expert analysis of underlying causes, recommendations are made for system redesign to improve performance and reduce errors and injuries.

In Australia, for example, over 200 health-care organizations or health services voluntarily send incident reports to the Australian Incident Monitoring System (AIMS) sponsored by the Australia Patient Safety Foundation (APSF). AIMS uses the Healthcare Incident Types (HIT) classification system, which elicits very detailed information from the reporter regarding generic incident types, contributing factors, outcomes, actions, and consequences. The Japan Council for Quality Health Care collects voluntarily reported adverse events from health-care organizations in Japan, particularly sentinel cases with root cause analysis. A research team led by Tokai University asks health-care organizations to voluntarily pool their events, which are then aggregated and results disseminated. In 2003, the Ministry of Health, Labour and Welfare patient safety committee recommended a national reporting system. The National Reporting and Learning System (NRLS) in England and Wales is another example of a learning system. NRLS receives reports of patient safety incidents from local health-care organizations.

Accountability systems
Reporting in accountability systems is usually mandatory and restricted to a list of defined serious events (also called “sentinel” events) such as unexpected death,transfusion reaction, and surgery on the wrong body part. Accountability systems typically prompt improvements by requiring an investigation and systems analysis (“root cause analysis”) of the event. Few regulatory agencies have the resources to perform external investigations of more than a small fraction of reported events, however, which limits their capacity to learn. In Slovenia, a brief description of a sentinel event must be sent to the Ministry of Health within 48 hours, and 45 days later a satisfactory analysis with corrective actions must be submitted or else a follow-up consultation with the Ministry occurs. The Czech Republic has reporting requirements that follow from their accreditation standards. The Netherlands has a two-tiered process. The Health Care Inspectorate, the agency accountable for taking actions against substandard performance, mandates hospitals to report adverse events that have led to death or permanent impairment. Other adverse events are reported voluntarily. There is interest in moving towards a more uniform blame-free reporting system to aggregate events nationally. A number of states in the United States have reporting systems that require hospitals or other providers to report certain types of serious, usually preventable events.

Most accountability systems not only hold health-care organizations accountable by requiring that serious mishaps be reported, they provide disincentives to unsafe care through citations, penalties or sanctions. The effectiveness of these systems depends on the ability of the agency to induce health-care organizations to report serious events and to conduct thorough investigations. Accountability systems can (and should) be learning systems if investigations are carried out and if the lessons learned are disseminated to all other providers by the agency. For example, the Danish Health Care System recently passed an Act on Patient Safety that requires health-care providers to report adverse events so information can be shared and aggregated for quality improvement.

Confidentiality and public access to data
Experience has shown that learning systems are most successful when reports are confidential and reporters do not feel at risk in sharing information about errors. Indeed,some feel it is only with such safe reporting systems that subtle system issues and the multitude of contributing factors will be uncovered. From a pragmatic standpoint, many believe that protecting the confidentiality of health-care organizations significantly enhances participation in reporting.

However, some citizen advocacy groups have called for public disclosure of information uncovered during investigations of serious adverse events, asserting the Public’s right to know about these events. Surveys in the United States show that 62–73% of Americans believe that health-care providers should be required to make this information publicly available. Nonetheless, all but three states in the United States have statutes that provide legal protection of confidentiality.

Internal reporting
Reports to an agency or other national body from a hospital or other health-care organization usually originate from a report within the institution. While such report say merely reflect statutory requirements, an institution that values patient safety will have an internal reporting system that captures much more than that. The objectives of an internal reporting system for learning are first, to identify errors and hazards, and then through investigation to uncover the underlying systems failures, with the goal of redesigning systems to reduce the likelihood of patient injury. The key conceptual point here, and the heart of a non-punitive approach to error reporting, is the recognition that adverse events and errors are symptoms of defective systems, not defects themselves. Reporting, whether retrospective (adverse events and errors) or prospective (“hazards”, or “errors are waiting to happen”) provides the entry point into investigation and analysis of system’s defects which, if skillfully done, can lead to substantial system improvements. Reporting is one way to get this type of information, but not the only way. Ideally, internal reporting systems should go hand in hand with external reporting systems, by identifying and analyzing events that warrant forwarding to external reporting agencies. Conversely, external reporting systems are most effective when they are an extension of internal systems.

Current Adverse Event Reporting Systems
Currently the adverse events are reported by health care providers, consumers and pharmaceutical companies. Sometimes the consumers report to the pharmaceutical companies which then the company reports to the FDA. There are several databases which allow the reporting of adverse events such as FDA’s Medwatch online reporting and several commercial softwares and databases such as oracle’s Adverse Event Reporting System have been developed for reporting adverse events along with benefit/risk assessment of the concerned product. Oracle’s AERS not only are the single source of adverse event , they even produce regulatory reports from standard templates for regulations like Medwatch 3500a, CIOMS I, NDA Periodic, PSUR, IND Safety Update, Yellow Card, BfArM, Medwatch for Device, VAERS etc. They even monitor safety issues and incidents over time using audit trail and product tracking, however apart from sophisticated softwares there are simple databases which a lay man could even enter any adverse events he has experienced apart from the health care practitioners such as FDA’s Medwatch form 3500A, Please report all significant adverse events that occur after vaccination of adults and children, even if you are not sure whether the vaccine caused the adverse event. VAERS, software, which allows online reporting of all significant adverse events that occur after vaccination of adults and children, even if the reporter is unsure whether the vaccine has caused the adverse event.

Reporting adverse events to institutional review boards and other independent boards
Current systems for reporting adverse events to institutional review boards (IRBs) are a bit messy and problematic because these reports do not contain the complete information and even these reports are very hard to be analysed since they are unsystematic. Apart from this, FDA has limited authority over the IRB s, however to address these issues, Office of Human Research protection (OHRP) created a draft guidance document titled Guidance on Reporting and Reviewing Adverse Events and Unanticipated Problems Involving Risks to Subjects or Others, that contained regulations to assist IRBs, investigators, research institutions, HSS agencies that conduct or sponsor human subjects research, and other interested parties. However more collaborative efforts are needed to improvise the adverse event reporting system.

Other independent boards, such as The Centers for Medicare and Medicaid Services (CMS) maintain a database that collects safety data about medications and medical devices and have even will also be establish Medicare Patient Event Safety Monitoring System that would examine the adverse events in the near future .the basic purpose of this board is to compile the medical data of the patient for the better management of the reimbursement issues.

However we need to focus on a reward based system that shows a distinct safety profile . According to Dr Woods’s proposal drugs that lacked long-term safety data would be clearly identified as such and in this way, physicians could make the appropriate choice of medication with their patients. A fundamental issue would be the design of these safety studies, which under Dr. Wood’s proposal would require FDA approval. In other words, extended exclusivity would be offered only for well-designed studies structured to answer important clinical questions. Another Forum member Robert Califf proposed a clinical trial “light” system, in which new users of drugs would be notified about known drug risks and benefits. The system would indicate that the drug being prescribed had recently been approved but that information concerning both risks and benefits was being developed. Patients would be provided information to report any adverse events and asked to participate in follow-up studies concerning the medication.

Pharmacovigilance Activities in India:

In India CDSCO has initiated the National Pharmacovigilance program under Family Welfare, and Government of India, where the national pharmacovigilance centers would be responsible for coordinating the program. The National Pharmacovigilance Advisory Committee (NPAC) would thereafter monitor the performance of various Zonal Pharmacovigilance Centre(ZPC), Regional Pharmacovigilance Centre(RPC), and peripheral centers and performs the functions of "Review Committee" for this program and would also recommend possible regulatory measures based on pharmacovigilance data received from various centers. The National Centre will operate under the supervision of the NPAC to recommend procedures and guidelines for regulatory interventions.

The National Pharmacovigilance Program (NPP) would operate with some definite objectives that include creating awareness and a sense of responsibility for several healthcare professionals and NGOs in the drug monitoring and information dissemination process. The NPP has the vision to achieve a benchmark for global drug monitoring endeavors.

Periodic Safety Update Reports shall be expected to be submitted every 6 monthly for the first 2 years of marketing in India, and annually for the subsequent 2 years. In addition, training programs and interaction meetings shall be held every 6 months after the initial training. All data generated (including reporting forms) will be stored and preserved for the purpose of archiving for a minimum period of 5 years at the ZPCs. The reporting of seemingly insignificant or common adverse reactions would be important because it may highlight a widespread prescribing problem

New approaches for improving reporting systems

Although there are several reporting systems for collecting adverse events, there is a need of developing highly sensitive and accurate system that would capture the adverse events worldwide. The new methods should be able to capture “high-frequency, high-impact” cases that are not detected with the current systems.
There can be several approaches for improving the current adverse event reporting system such as to have incentives for long-term safety studies.” This, however, would cause a long delay before drug approval and would not be cost-efficient. It would also entail discussion about which drugs would be subject to long-term study. Another approach is to conduct long-term safety studies after approval. This again requires consideration of which drugs would be chosen for study or whether all drugs should be studied. Another way is to ensure the completion of safety studies is to offer extended exclusivity to companies that have acquired data to demonstrate that their drug is safe in the long term. This makes the drug more valuable to consumers and to the company.

References
1.http://www.fda.gov/Drugs/GuidanceComplianceRegulatoryInformation/Surveillance/AdverseDrugEffects/default.htm
2. http://en.wikipedia.org/wiki/Adverse_Event_Reporting_System
3. http://www.drugcite.com/
4. http://www.fdable.com/
5. www.fda.gov/Drugs/InformationOnDrugs/ucm135151.htm
6. www.biotech.com/adverseEventReportSys.php

Tuesday, August 5, 2008

FDA regulations on eClinical trials

The following general guidelines are proposed by FDA in reference in Computerized systems in clinical trials, the complete document is available at http://www.fda.gov/ora/compliance_ref/bimo/ffinalcct.htm

A. Each study protocol should identify at which steps a computerized system will be used to create, modify, maintain, archive, retrieve, or transmit data.
Comment : This means that the study protocol has to receive input from the data manager. Most of the companies include these steps as SOPs so that they can be referenced in the study protocol.

B. For each study, documentation should identify what software and, if known, what hardware is to be used in computerized systems that create, modify, maintain, archive, retrieve, or transmit data. This documentation should be retained as part of study records.
Comment : This level of detail is not mandatory, and is often missed out in most study protocols.

C. Source documents should be retained to enable a reconstruction and evaluation of the trial.
Comment : This requirement is fulfilled via a Audit trial so that FDA/ independent audits can be performed.

D. When original observations are entered directly into a computerized system, the electronic record is the source document.
Comment : The specific condition where this rule will not apply is for lab data, the source data is obtained electronically from the lab. The data is then batch loaded into the CDM system, still the source data is the lab data.

E. The design of a computerized system should ensure that all applicable regulatory requirements for recordkeeping and record retention in clinical trials are met with the same degree of confidence as is provided with paper systems.
Comment : 21 CFR Part 11 and ER/ES are two common regulatory requirements. The "degree of confidence" is set via a validation process for each CDM system.

F. Clinical investigators should retain either the original or a certified copy of all source documents sent to a sponsor or contract research organization, including query resolution correspondence.
Comment : Though this sounds simple, it is complicated for investigators to maintain a source data archive.

G. Any change to a record required to be maintained should not obscure the original information. The record should clearly indicate that a change was made and clearly provide a means to locate and read the prior information.
Comment : All updates on source data will include a reason for change, data and time of change, person initiating the change, data value before change and data value after change. Sometimes the change in data may require sign-off by a study manager.

H. Changes to data that are stored on electronic media will always require an audit trail, in accordance with 21 CFR 11.10(e). Documentation should include who made the changes, when, and why they were made.
Comment : Refer to above

I. The FDA may inspect all records that are intended to support submissions to the Agency, regardless of how they were created or maintained.
Comment : Refer to above

J. Data should be retrievable in such a fashion that all information regarding each individual subject in a study is attributable to that subject.
Comment : Refer to above

K. Computerized systems should be designed: (1) So that all requirements assigned to these systems in a study protocol are satisfied (e.g., data are recorded in metric units, requirements that the study be blinded); and, (2) to preclude errors in data creation, modification, maintenance, archiving, retrieval, or transmission.
Comment : Refer to above

L. Security measures should be in place to prevent unauthorized access to the data and to the computerized system.

Electronic Health Records (EHR) in clinical trials

Electronic Health Records (EHR) are standard instruments used to capture patient encounter data in clinical practice. They offer some key benefits in relation to clinical trials by supporting : 1. Increased patient recruitment, 2. Increased physician participation.

Study Set-up
Query EHR database to establish number of potential study candidates.
Incorporate study manual or special instructions into EHR “clinical content”for study encounters
Study execution
Incorporate study-specific data capture (just as you would do with a CRF in a clinical trial) as part of routine clinical care / clinical documentation workflow.
Auto-populate study data elements (for example demographics) into CRFs from other parts of the EHR database.
Embed study-specific data requirements (modules not already included in the EHR) as special tabs/documentation templates using structured data entry.
Implement rules/alerts to ensure compliance with study data collection requirements (EHR systems have inbuilt validation checks)
Create range checks and structured documentation checks to ensure valid data entry

Study Enrollment
Implement study screening parameters into patient registration and scheduling.
Query EHR database to contact/recruit potential candidates and notify the patient’s provider(s) of potential study eligibility.

Submission & Reporting
Provide data extraction formats that support data exchange standards (for example CDISC)
Document and report adverse events (Note : EHRs often use ICD-9/10 coding, while CRFs would need MedDRA codes)

xml

XML or extensible markup language is exactly what the acronym says. XML is a non-proprietary textual representation of data/strings and atributes.XML structure is defined by a schema or a DTD (document type definition). There are a number of clinical research/health care standards based on xml such as HL7, CDISC, JANUS etc.,XML basically defines content/data as tags and attributes and data elements can be defined in namespaces. The intention of this post is not to teach you xml but to give some basics of why you should be aware of xml in relation to Clinical Research.Recently Microsoft has been in conflict with many open source groups in relation to their OOXML standard, There has been complaints and concerns that this standard has been rigged

CDISC

CDISC
CDISC mission statement from CDISC website says "CDISC is a global, open, multidisciplinary, non-profit organization that has established standards to support the acquisition, exchange, submission and archive of clinical research data and metadata. The CDISC mission is to develop and support global, platform-independent data standards that enable information system interoperability to improve medical research and related areas of healthcare. CDISC standards are vendor-neutral, platform-independent and freely available via the CDISC website."
We will cover each CDISC standard in detail in the coming posts, here is a summary table with links to the current standard specification at http://www.cdisc.org. To give an overview the different parts of the CDISC standard are related as below to the clinical trial process
CDISC Standards in Production
Submission Data Standards Team(For submission of data-sets to regulatory)
(SDTM IG V3.1.1)(SDTM V1.1)(SDTM IG V3.1)
WebSDM edit checks for (SDTM 3.1.1)
Operational Data Modeling Team(ODM V1.3) (ODM V1.2.1) See also (eSDI Document)
Analysis Dataset Model Team(ADAM)
Laboratory Standards Team(LAB)
Standard for Exchange of Non-clinical Data(SEND V2.3)
Case Report Tabulation Data Definition Specification (define .xml)(CRT-DDS V1.0)
Terminology(Terminology)

Standards in Development

Submission Data Standards Team
SDTM IG V3.1.2 DraftSDTM V1.2 DraftMetadata Submission Guidelines, Appendix to the SDTM IG V3.1.1
Protocol Representation Group(PRG)
Clinical Data Acquisition Standards Harmonization (CDASH)(CDASH)
Terminology(Terminology)
Cardiovascular and Tuberculosis Data Standards(Cardiovascular and Tuberculosis Data Standards)


CDISC SDTM standard
Inline with the Critical Path Initiative CDISC has developed three main standards to improve the efficiency of clinical trial projects, namely : Operational Data Model (ODM), the Study Data Tabulation Model (SDTM) and the Analysis Data Model (ADaM).
The SDTM defines a standard structure for study data tabulations. These are to be submitted as part of a product application to a regulatory authority such as FDA.
The SDTM was prepared by the CDISC Submission Data Standards (SDS) Team to guide the organization, structure, and format of tabulation data sets for study data submitted to regulatory authorities. Data tabulation data sets are one of four ways to represent the human subject Case Report Tabulation (CRT) and equivalent animal data submitted to the FDA.
The SDTM is composed of 30+ defined domains within six broad categories. Each domain represents a file structure and contains a particular type of data associated with clinical trials, such as demographics, vital signs or adverse events.
The model also provides the ability to create custom-defined domains with sets of standard variable definitions. Variables in common across domains all have similar name extensions, and the standard specifies the beginning prefix of all variables be a (typically) two-letter domain abbreviation.

CDISC ODM Standard
The Operational Data Model (ODM) provides a format for representing the study metadata, study data and administrative data associated with a clinical trial.
It represents only the data that would be transferred among different software systems during a trial, or archived after a trial.
It need not represent any information internal to a single system, for example, information about how the data would be stored in a particular database.
The ODM model assumes that a study's clinical data will consist of several kinds of entities. These include:
subjects
study events (a series of forms connected to an event)
forms (aggregations of item groups)
item groups (groups of items that will be analyzed together)
items (single data item such as Hb%)
annotations (comment applied to any of the above)

CDISC ADaM standard
ADaM is a CDISC standard to submit analysis data to FDA. Key is to understand that ADaM is a SDTM model for providing analysis data, programs and data definitions. The principles of ADaM is aimed at providing a clear and unambiguous communicationof the content, source and quality of the datasets submitted in support of the statistical analysis performed by the sponsor. This in turn would support the machine-readable description for the JANUS data repository.
Analysis datasetsAnalysis datasets are datasets created to support specific analyses.
Each dataset is provided as a SAS Transport (XPORT) file.
Programs should be provided as both ASCII text and PDF files and should include sufficient documentation to allow a reviewer to understand the submitted programs. ProgramsPrograms are scripts used with selected software to produce reported analyses based on these datasets.Analysis-level Metadata
ANALYSIS NAME –A unique identifier for this analysis. May include a table number or other sponsor- specific reference.
DOCUMENTATION –A text description documenting the analysis performed.
REASON –The reason for performing this analysis. Examples may include Pre-specified, Data-driven, Exploratory, and Regulatory Request.
DATASET –the name of the analysis dataset used should be linked to the analysis dataset used for this analysis. In most cases, this will be a single dataset. If multiple datasets are used, they should all be listed here.
PROGRAM –Analysis programs using the DATASET above as input can be described or included here.

define.xml and SDTM
Define.xml is the document which specifies the standard for providing Case Report Tabulations Data Definitions in an XML format for submission to regulatory authorities (e.g., FDA).
The XML schema used to define the expected structure for these XML files is based on an extension to the CDISC Operational Data Model (ODM).

Safety Reporting to FDA

We have received lot of requests to write about Safety related reporting, coding and regulation. This blog will feature these aspects for the next 10 days, if you wish us to write on a specific topic please email us at contact@clinnovo.com. Thanks for your interest.
Pre-Approval - To IND
Unexpected fatal or life-threatening experience associated with the use of the drug
7 calendar day reports (telephone or fax)
From All Studies Worldwide (Serious, Drug-Related and Unexpected)
15 calendar day reports (telephone or fax)
Findings from long term tox tests in laboratory animals suggesting a significant risk to humans (mutagenicity, teratogenicity, carcinogenicity)
15 calendar day reports (telephone or fax)
Spontaneous Reports from Marketing Outside the U.S. (Serious and Unexpected)
15 calendar day reports (telephone or fax)
Reports in the scientific literature including unpublished manuscripts (Serious and Unexpected)
15 calendar day reports (telephone or fax)
Reports from foreign regulatory authorities (Serious and Unexpected)
15 calendar day reports (telephone or fax)
From Studies Worldwide (Serious)
Annual IND reports
Post-Approval - To IND
From IND Studies (Serious, Drug-Related and Unexpected)
15 calendar day reports (telephone or fax)
From IND Studies (Serious)
15 calendar day reports (telephone or fax)
Post-Approval - To NDA
From All Studies Worldwide (Serious, Drug-Related and Unexpected)
15 calendar day reports (telephone or fax)
Spontaneous Reports Worldwide (Serious and Unexpected)
Spontaneous and Periodic
Consequences of not following the schedule
Pre-Approval - Termination of IND
21 CFR 312.44 in Phase 1, 2 or 3 : (b)(1)(vii) “The sponsor fails promptly to investigate and inform the Food and Drug Administration and all investigators of serious and unexpected adverse experiences in accordance with part 312 section 32 or fails to make any other report required under this part.
Post-Approval- Withdrawal of NDA
21 CFR 314.80 (K) : "If an applicant fails to establish and maintain records and make reports required under this section FDA may withdraw approval of the application and, thus, prohibit continued marketing of the drug product that is the subject of the application.”

standardized MedDRA Queries

Definition
Groupings of MedDRA terms from one or more System Organ Classes (SOCs) that relate to a defined medical condition or area of interest.

Purpose
To support the retrieval of potentially relevant safety reports that includes a broad selection of terms that may relate to signs, symptoms, diagnoses, syndromes, physical findings, laboratory and other physiologic test data, etc., that are associated with a given medical condition or area of interest
Benefits
Uniformity of search strategies and results across organizations
Reproducibility of search strategies and results from regulatory perspective
Convenience of pre-defined grouping based on a medical condition of interest
Maintenance by MSSO and standard frame of reference
Example
SMQs combine narrow and broad search strategies allowing as much safety related information as relevant to be tagged to the query.
Acute Renal Failure definition : Acute renal failure is a syndrome characterized by a relatively rapid decline in renal function that leads to the accumulation of water, crystalloid solutes, and nitrogenous metabolites in the body.
Acute Renal Failure Narrow SMQ: Acute prerenal failure, Anuria, Azotemia, Dialysis, Hemodialysis, Neonatal anuria, Nephropathy toxic, Oliguria, Peritoneal dialysis, Renal failure acute, Renal failure neonatal, Renal impairment neonatal, and Renal impairment, and Renal insufficiency.
Acute Renal Failure Broad SMQ: Albuminuria, Blood creatinine abnormal, Blood creatinine increased, Blood urea abnormal, Blood urea increased, Blood urea nitrogen/creatinine ratio increased, Creatinine renal clearance decreased, Edema due renal disease, Hepatorenal failure, Nephritis, Nephritis interstitial, Proteinuria, Renal clearance decreased, Renal function tests abnormal, Renal transplant, Renal tubular disorder, Renal tubular necrosis, Tubulointerstitial nephritis.
Development of SMQs
SMQs are developed by consortium of swiss based Council For International Organization Of Medical Sciences (CIOMS) and MSSO. They are tested on one instance of federal safety database and one industrial partner database.
MedDRA unleashed
MedDRA stands for Medical Dictionary for Regulatory Activities
WHO-ART would be WHO's Adverse Reaction Terminology
ICD-9CM is International Classification of Diseases, 9th Revision Clinical Modification
A more rarer abbreviation : MSSO stands for Maintenance Service and Support Organization
History
Just as they did with James Bond 007, MedDRA was originally developed by UK's regulatory authority. Medicines Control Agency (MCA), and is a terminology for classifying adverse effects and medical history.
Applications of MedDRA
Data Capture and Coding : mainly efficacy data and post-market safety surveillance
Data Retrieval : Safety data reporting and pharmacovigilance, periodic safety reports
Data Analysis : End of trial safety data tabulation, thresholding (as a cut-off)
Regulatory Actions : Product label creating and maintenance
MedDRA hierarchy
The dictionary is structured into 5 levels namely : System Organ Class (SOC) > High level term group (HLGT) > High Level Term (HLT) > Preferred Term (PT) > Lowest Level Term (LLT). The association between PT and LLT is one to one, and for the rest it is many to one.
How to get MedDRA
MedDRA is a licensed software for non-regulators, and comes as a ASCII text file separated by $ signs. The data can be then easily fed into any relational database system such as mysql, oracle etc.,
What is the role of MSSO ?
MedRA is handled by www.meddramsso.com which is responsible change requests, help desk and handling the user group. One of the early issues with MedDRA adoption was the need to translate from COSTART or WHO-ART to MedDRA. The more recent issue has been the need to keep up with the new updates in MedDRA. MSSO tries to soothe the pain felt by companies in this process of changes and updates.