Standardisation and classification of medical language data are dependent on the use of controlled medical vocabularies. In the pharmacovigilance setting, adverse drug reactions (ADRs) are coded using terminological systems such as the WHO Adverse Reaction Terminology (WHO-ART), Coding Symbols for a Thesaurus of Adverse Reaction Terms (COSTART) and Hoechst Adverse Reactions Terminology System (HARTS). The Medical Dictionary for Drug Regulatory Affairs (MEDDRA), derived from the Adverse Drug Reactions Online Information Tracking (ADROIT) terminology, was accepted as the basis for development of a new terminology at the fourth International Conference on Harmonisation for the Registration of Pharmaceuticals for Human Use (ICH 4) in July 1997. MEDDRA was extensively modified to become MedDRA, the Medical Dictionary for Regulatory Activities project. MedDRA is now maintained, developed and distributed by the Maintenance and Support Services Organization (MSSO).
The purpose of MedDRA is to describe the steps of drug development and regulatory issues about human exposure. It includes terms for the description of ADRs, indications, signs and symptoms, family history, investigations and surgical procedures. It is used in the US FDA Adverse Event Reporting System (AERS) and Vaccine Adverse Event Reporting System (VAERS) databases, the European Medicines Agency (EMEA) Eudrawatch system and the Japanese prescription-event monitoring system. Since January 2003, all electronic exchange of case reports of ADRs in the EU, Iceland, Liechtenstein and Norway should be coded with MedDRA.
MedDRA terms are organised in five levels: system organ class (SOC), high level group term (HLGT), high level term (HLT), preferred term (PT) and low level term (LLT). The preferred level of analysis is the PT. PTs are classified according to SOCs, which are clinical conditions (medical procedures or patient history) relevant for the pre- and post-marketing of drugs, and SOCs used to describe diseases or findings. PTs are grouped in HLTs and then in HLGTs in the same SOC.
Each PT is intended to represent a unique medical concept: it is the term preferred for use in the regulatory environment and is formatted according to MedDRA conventions. Eponymous terms may be used if recognized internationally. A PT may describe a single syndrome, even though a syndrome represents a collection of signs and symptoms. Each PT is duplicated as an LLT and may have subordinate to it one or more other LLTs that are synonyms, lexical variants or alternative spellings of the PT. In addition, some LLTs describe conditions that are more precise or specific than the PT to which they are linked; whilst not synonymous, they are considered not to warrant PT status from a pharmacovigilance perspective. Each PT is represented only once under a particular SOC, to which it is connected vertically via a single High Level Term (HLT), which in turn is fixed in location and represented only once in that SOC under one High Level Group Term (HLGT). It is a rule that there is only one route from LLT to PT to HLT to HLGT within the SOC.
Google Search
Thursday, September 2, 2010
Monday, August 30, 2010
What Does An SGML File Look Like?
SGML, or Standard Generalized Markup Language, is an international standard for the description of marked-up electronic text. SGML is a meta language, which is a means of formally describing a language. More specifically, SGML is a markup language that has been used in the publishing industry to associate document format with text.
A basic design goal of SGML was to ensure that documents encoded according to its provisions should be transportable from one hardware and software environment to another without loss of information. The structure of SGML is based on a grouping of sections and elements that are annotated by start and end tags. Tags are user-friendly phrases used to indicate the data elements contained within the tags. For example:
19690218
In this example, the starting and ending tags "patient birthdate" indicate that the data within the tags is the patient's birthdate. The relationship and order of data elements is further defined by document type definition (DTD). DTDs are document-specific specifications for the structure of an SGML document. In the following example, the DTD has specified that the order of the information be presented as:
19690218/patientbirthdate> 29 years .
Using the above example the data must be presented in the following order to be in conformance with the DTD:
Patient birth date
Patient onset age
Patient onset age unit
If the data elements are presented in any other order (e.g., patient onset age, patient onset age unit, patient birth date) the elements are not in conformance with the SGML DTD for the document.
For electronic submission of adverse event data, a specific SGML DTD has been specified by the ICH. The ICH ICSR DTD defines the specific data elements to be included for electronic submission of adverse event data, the order of the elements, and their interrelationship.
A basic design goal of SGML was to ensure that documents encoded according to its provisions should be transportable from one hardware and software environment to another without loss of information. The structure of SGML is based on a grouping of sections and elements that are annotated by start and end tags. Tags are user-friendly phrases used to indicate the data elements contained within the tags. For example:
In this example, the starting and ending tags "patient birthdate" indicate that the data within the tags is the patient's birthdate. The relationship and order of data elements is further defined by document type definition (DTD). DTDs are document-specific specifications for the structure of an SGML document. In the following example, the DTD has specified that the order of the information be presented as:
Using the above example the data must be presented in the following order to be in conformance with the DTD:
Patient birth date
Patient onset age
Patient onset age unit
If the data elements are presented in any other order (e.g., patient onset age, patient onset age unit, patient birth date) the elements are not in conformance with the SGML DTD for the document.
For electronic submission of adverse event data, a specific SGML DTD has been specified by the ICH. The ICH ICSR DTD defines the specific data elements to be included for electronic submission of adverse event data, the order of the elements, and their interrelationship.
What is the difference between E2B and E2BM?
E2B is the international standard for the transmittal of electronic safety data signed as an ICH Step 4 document in July1997. E2BM clarifies and resolves issues raised in the three regional pilot studies. The revised document (E2BM) is intended to further advance the electronic exchange of safety information and approach a true EDI (Electronic Data Interchange) standard. The E2B document is implemented by M2 Specification Version 2.24 DTD Version 2.0. The E2BM document is implemented by M2 Specification Version 2.3 DTD Version 2.1
Subscribe to:
Posts (Atom)