Understanding the New Latest ICH E2B (R3) Guidelines:
The International Conference on Harmonization (ICH) has released step 4 guidance for a E2B (R3) format for electronic exchange of Individual Case Summary Reports (ICSR). The new format is based on Health Level 7 Version 3 (HL7 V3) messaging standard.
ICH Decided to collaborate with SDO (Strandar development oraganization) to come with standar regulation for E2B.E2B (R3) messages uses International Standard Code set such as ISO 5218 (for human sexes), ISO 639-2 (for names of Languages), UCUM (for units of measurements).
The ICH E2B (R3) message standard is founded on the ISO
/ HL7 27953-2 standard, which is constrained from ISO / HL7 27953-1to provide an ‘ICH subset’of the standard supporting electronic messaging for the ICH E2B(R3) data elements.
Why ICSR reporting Needed ?
ICSRs are exchanged primarily to enhance patient safety thereby promoting public health.Furthermore, ICSRs need to be transmitted across stakeholder communities throughout the health product lifecycle, during clinical investigation as well as for continued safety monitoring
once authorised for marketing. Electronic reporting facilitates the transfer of information and makes safety data readily available for further processing and analysis. These advantages allow regulators, MAHs, healthcare professionals (HCPs) and consumers to make better-informed
decisions regarding the use of health products.
Minimum requirement for ICSR reporting :
The minimum information for valid safety report should include at least:
one identifiable patient – any one of several data elements is considered sufficient to define
an identifiable patient (e.g. initials, age, sex);
one identifiable reporter – any one of several data elements is considered sufficient to define
an identifiable reporter (e.g. initials, address, qualifications);
one adverse event/reaction (or outcome); and
one suspect or interacting drug.
in addition to the minimum information required for an ICSR report certain specific administrative information should be provided to properly process the report:
Sender’s (case) Safety Report Unique Identifier (C.1.1);
Type of Report (C.1.3);
Date of Most Recent Information for This Report (C.1.5);
Dose This Case Fulfil the Local Criteria for an Expedited Report? (C.1.7);
Worldwide Unique Case Identification (C.1.8);
Reporter’s Country Code (C.2.r.3);
Sender’s Organisation (C.3.2); and
When type of report=‘Report from study’, Study Type Where Reaction(s) / Event(s)Were Observed (C.5.4).
This applies to all types of ICSRs including initial case reports, follow-up
information, and cases to be amended or nullified in fully structured format using the relevant E2B(R3) data elements and applicable standard terminologies. Those terminologies include;
ISO (country codes, gender codes and language codes),
MedDRA (e.g. medical history,indication, and reaction / event),
UCUM (units of measurement),
ICH M5 (IDMP).
Why Harmonization Needed ?
Without harmonization, the existence of a multiplicity of message and/or content standards across regions and regulatory jurisdictions would result in diseconomies of scale and increase the burden for reporters. A lack of harmonisation might lead to difficulties in reconciling ICSRs
on the global level. A harmonised standard should stimulate vendors to develop ‘off-the-shelf’ tools that are interoperable due to the standard itself. A harmonised standard will also help maximise forward compatibility of data and minimise the complexities of backward
compatibility. For these reasons, health authorities and the pharmaceutical industry are moving in unison toward a meaningful, harmonised standard for use by all constituents.
What is Message standards?
HL7 Ver 3
The HL7 model-driven methodology is used to develop consensus-based standards for healthcare system interoperability and information exchange.HL7 V3 messages are based on an XML encoding syntax.
The HL7 version 3 (V3) messaging standard deals with a static model of health care informationas viewed within the scope of HL7 standards development activities.ISO recognises HL7 as an
accredited partnering organisation for mutually issuing standards
ISO / HL7 27953-2 standard is built upon the Health Level 7 (HL7) ICSR Release 3 standard (or HL7 ICSR R3).
The HL7 ICSR R3 standard is a particular message based on the HL7 V3.
Who uses what?
FDA require HL7 Standard
EMA require standard to be ISO or CEN
what is OID?
An Object Identifier (OID) is a sequence of numbers to uniquely identify an object. The numbers represent a hierarchically-assigned namespace, formally defined using the International Telecommunications Union ASN.1 standard. These numbers are written either as a string of digits separated by dots or as a list of named ‘branches.’ For example, the MedDRA dictionary of terms is identified by the OID 2.16.840.1.113883.6.163 which also represents
FORMAT OF DATA ELEMENT:
E2B (R3) data elements have a hierarchical tree structure. It consists of two major sections A and B,
where A contains administrative and identification information, and B contains information on the case.
The subsidiary sections are categorize by the nature of the data, and are:
Section A
o C.1 – Identification of the Case Safety Report;
o C.2- Primary Source(s) of Information;
o C.3 – Information on Sender of Case Safety Report;
o C.4 – Literature Reference(s);
o C.5 – Study Identification.
Section B
o D – Patient Characteristics;
o E – Reaction(s)/ Event(s);
o F – Results of Tests and Procedures Relevant to the Investigation of the Patient;
o G – Drug(s) Information; and
o H – Narrative Case Summary and Further Information.
Introduction of NULL Flavor in R3:
We have seen in R2 that ICSR files transmitted with NULL value in few DTD elements. Blank DTD does not indicates if the value is not known or not applicable or not shared due to Privacy. To differentiate the values of NULL DTD in R2, NULL Flavor introduced in R3.Most ICSRs, a number of data elements will be unknown, and therefore, not transmitted in the report. Since ICSR information will be transmitted electronically, it is unnecessary to assign values to unknown, optional data elements. However, in certain cases it is important to understand if a data element is null because it is not applicable or because it is
unknown or because it is ‘protected’ by privacy legislation.
In those cases, provisions for expressing a null value are included in the message for a data element to indicate the absence of data and reason.
CODE NAME DEFINATION
NI =No Information
“No information whatsoever can be inferred from this
exceptional value. This is the most general exceptional value. It is also the default exceptional value.”
MSK Masked
“There is information on this item available but it has not been
provided by the sender due to security, privacy or other
reasons. There could be an alternate mechanism for gaining
access to this information. Note: using this nullFlavor can
provide information considered to be a breach of
confidentiality, even though no detail data is provided. Its
primary purpose is for those circumstances where it is
necessary to inform the receiver that the information does exist
without providing any detail.”
UNK= Unknown Value
is application but no known at this time
NA= Not Applicable “No proper value is applicable in this context (e.g. last menstrual period for a male).”
ASKU= Asked But Unknown Information was sought but not found (e.g. patient name was asked but could not be found)
NASK= Not Asked : “This information has not been sought (e.g. patient was not asked)”
NINF=Negative Infinity Negative infinity of numbers
PINF=Positive Infinity Positive infinity of numbers
Date Format in R3:
HL7 uses a single format to represent dates and times:
CCYYMMDDHHMMSS.UUUU[+|-ZZzz]. Complete date time information down to seconds can be reported using this format. This date format makes it possible to provide data to the appropriate degree of precision.
‘Future dates’ cannot be transmitted in an ICH ICSR message.When transmissions occur across different time zones, senders and receivers should configure their systems (e.g. attach the ZZzz offset to Coordinated Universal Time) to prevent dates and times to be interpreted as ‘future dates’.
iche2br3 