INTERNATIONAL COUNCIL FOR HARMONISATION OF

TECHNICAL REQUIREMENTS FOR PHARMACEUTICALS FOR

HUMAN USE

ICH E2B Implementation Working Group

Implementation Guide for

Electronic Transmission of Individual Case Safety Reports
(ICSRs)

E2B(R3) Data Elements and Message Specification

Version 5.02, 10 November 2016

ICH ICSR Implementation Guide 10 November 2016

Document History

Date of Title of Document Version Published for WG

Finalisation
February Maintenance of The ICH Guideline on 4.4.1 Step 4 E2B
Clinical Safety Data Management : Data
2001 document EWG
Elements For Transmission of Individual
Case Safety Reports E2B(M)*
*Renamed E2B(R2) in 2005
Electronic Transmission of Individual 2.3 M2
Case Safety Reports Message
EWG
Specification (ICH ICSR DTD v2.1)

May 2005 Revision of The ICH Guideline on 2.0 First Public E2B
Clinical Safety Data Management: Data
Consultation EWG
Elements for Transmission of
Individual Case Safety ReportsE2B(R)
June 2009 Electronic Transmission of Individual 1.31 First Step 2 M2 /
Case Safety Reports Message
for Testing E2B
Specification
Implementation Guide EWG
(ICH ICSR Message Version 3.96)
April 2010 Electronic Transmission of Individual 2.47 Second Step 2 M2 /
Case Safety Reports Implementation
for Testing E2B
Guide
Data Elements and Message Specification EWG
June 2011 Electronic Transmission of Individual 3.01 Second Public E2B
Case Safety Reports (ICSRs)
Consultation EWG
Implementation Guide
Data Elements and Message Specification
November Implementation Guide for Electronic 5.0 Reached Step E2B
Transmission of Individual Case Safety
2012 4 but no EWG
Reports (ICSRs)
Data Elements and Message Specification publication
April Editorial corrections made prior to 5.01 Step 4 E2B
publication of Step 4 – the accompanying
2013 document EWG
history spreadsheet should be consulted
for details of changes
November Editorial corrections and updates based on 5.02 Step 4 E2B
Q&A document
2016 document IWG

ICH ICSR Implementation Guide 10 November 2016

-1-
This document is protected by copyright and may be used, reproduced, incorporated into other
works, adapted, modified, translated or distributed under a public license provided that the
ICH's copyright in the document is acknowledged at all times. In case of any adaption,
modification or translation of the document, reasonable steps must be taken to clearly label,
demarcate or otherwise identify that changes were made to or based on the original document.
Any impression that the adaption, modification or translation of the original document is
endorsed or sponsored by the ICH must be avoided.
The document is provided ‘as is’ without warranty of any kind. In no event shall the ICH or the
authors of the original document be liable for any claim, damages or other liability arising from
the use of the document.
The above-mentioned permissions do not apply to content supplied by third parties. Therefore,
for documents where the copyright vests in a third party, permission for reproduction must be
obtained from this copyright holder.

ICH ICSR Implementation Guide 10 November 2016

-2-
Table of Contents

INTRODUCTION ........................................................................................... 13
1.0 Purpose .................................................................................................. 14
1.1 Scope ........................................................................................................................... 14

1.2 Business Case ............................................................................................................. 14

2.0 Background ............................................................................................ 15

2.1 General Background and History of ICH ................................................................. 15

2.1.1 The ICH and its Partners .................................................................................. 15

2.1.2 History of ICH ICSR guidelines ........................................................................ 15

2.1.3 The Process of Revision in ICH ......................................................................... 16

2.2 Development of ICSR Standard under Joint Initiative ........................................... 16

2.3 Background of Message Standard............................................................................. 17

2.4 Representation of the Electronic ICSR ..................................................................... 18

2.4.1 Why Standardisation and Electronic ICSR Exchange are Needed ................ 18

2.4.2 How ICSRs Are Presently Transmitted and the Advantages of Electronic Submissions.......... 18

3.0 Essential Components............................................................................ 20

3.1 ICH ICSR Relational Diagrams ................................................................................ 21

3.2 Code Sets, Terminologies and Vocabularies for E2B(R3) ........................................ 23

3.2.1 Terminologies and Vocabularies Employed by the ICSR Message ................. 23

3.2.2 ICH Maintained Code Sets and Object Identifiers (OIDs) Created for the ICH ICSR ............. 27

3.2.3 International Standard Code Sets .................................................................... 30

3.3 ICH E2B(R3) Specifications for the Transmission of ICSRs ................................... 32

3.3.1 Minimum Information ....................................................................................... 32

3.3.2 Definition of Data Elements within a Message ............................................... 32

3.3.3 General Principles.............................................................................................. 33

3.3.4 Retransmission of cases ..................................................................................... 33

3.3.5 Notes on Format of Data Elements .................................................................. 34

3.3.6 General rules for Data Entry ............................................................................ 35

3.3.7 Details of ICH E2B(R3) Data Elements ........................................................... 38

ICH ICSR Implementation Guide 10 November 2016

-3-
3.4 ICH E2B(R3)DATA ELEMENTS ............................................................. 40
N.1 ICH ICSR Transmission Identification (batch wrapper) ...................... 40
N.1.1 Type of Messages in Batch .................................................................................... 40

N.1.2 Batch Number ........................................................................................................ 41

N.1.3 Batch Sender Identifier ......................................................................................... 41

N.1.4 Batch Receiver Identifier ....................................................................................... 42

N.1.5 Date of Batch Transmission .................................................................................. 42

N.2.r ICH ICSR Message Header (message wrapper) (repeat as necessary) . 42

N.2.r.1 Message Identifier ............................................................................................... 42

N.2.r.2 Message Sender Identifier .................................................................................. 43

N.2.r.3 Message Receiver Identifier ................................................................................ 43

N.2.r.4 Date of Message Creation ................................................................................... 43

C.1 Identificationofthe Case Safety Report ................................................. 44

C.1.1 Sender’s (case) Safety Report Unique Identifier .................................................. 45

C.1.2 Date of Creation...................................................................................................... 46

C.1.3 Type of Report......................................................................................................... 47

C.1.4 Date Report Was First Received from Source ...................................................... 47

C.1.5 Date of Most Recent Information for This Report ................................................ 48

C.1.6 Additional Available Documents Held by Sender ................................................ 48

C.1.6.1 Are Additional Documents Available? .......................................................... 48

C.1.6.1.r Documents Held by Sender (repeat as necessary) ..................................... 49

C.1.7 Does This Case Fulfil the Local Criteria for an Expedited Report? .................... 49

C.1.8 Worldwide Unique Case Identification ................................................................. 50

C.1.8.1 Worldwide Unique Case Identification Number .......................................... 50

C.1.8.2 First Sender of This Case............................................................................... 51

C.1.9 Other Case Identifiers ............................................................................................ 51

C.1.10.r Identification Number of the Report Linked to This Report (repeat as necessary) ...... 53

C.1.11 Report Nullification / Amendment ...................................................................... 53

ICH ICSR Implementation Guide 10 November 2016

-4-
C.2.r Primary Source(s) of Information (repeat as necessary) ..................... 55
C.2.r.1 Reporter’s Name .................................................................................................. 56

C.2.r.2 Reporter’s Address and Telephone ..................................................................... 57

C.2.r.3 Reporter’s Country Code ..................................................................................... 59

C.2.r.4 Qualification ......................................................................................................... 60

C.2.r.5 Primary Source for Regulatory Purposes ........................................................... 60

C.3 Information on Sender of Case Safety Report ....................................... 61

C.3.1 Sender Type ............................................................................................................ 61

C.3.2 Sender’s Organisation ............................................................................................ 62

C.3.3 Person Responsible for Sending the Report.......................................................... 62

C.3.4 Sender’s Address, Fax, Telephone and E-mail Address....................................... 64

C.4.r Literature Reference(s) (repeat as necessary)..................................... 67

C.4.r.1 Literature Reference(s)........................................................................................ 67

C.4.r.2 Included Documents ............................................................................................ 67

C.5 Study Identification ............................................................................... 68

C.5.1.r Study Registration (repeat as necessary) ........................................................... 68

C.5.1.r.1 Study Registration Number ........................................................................ 68

C.5.1.r.2 Study Registration Country ........................................................................ 69

C.5.2 Study Name ............................................................................................................ 69

C.5.3 Sponsor Study Number .......................................................................................... 69

C.5.4 Study Type Where Reaction(s) / Event(s) Were Observed ................................... 70

D Patient Characteristics ............................................................................ 71

D.1 Patient (name or initials) .......................................................................................... 75

D.1.1 Patient Medical Record Number(s) and Source(s) of the Record Number ................ 75

D.2 Age Information......................................................................................................... 77

D.2.1 Date of Birth ...................................................................................................... 77

D.2.2 Age at Time of Onset of Reaction / Event ........................................................ 78

D.2.2.1a Gestation Period When Reaction / Event Was Observed in the Foetus ............... 78

D.2.3 Patient Age Group (as per reporter) ................................................................ 79

D.3 Body Weight (kg) ....................................................................................................... 79

D.4 Height (cm) ................................................................................................................ 80

ICH ICSR Implementation Guide 10 November 2016

-5-
 D.5 Sex .............................................................................................................................. 80

D.6 Last Menstrual Period Date ..................................................................................... 80

D.7 Relevant Medical History and Concurrent Conditions (not including reaction / event) .... 81

D.7.1.r Structured Information on Relevant Medical History (repeat as necessary)

...................................................................................................................................... 81

D.7.2 Text for Relevant Medical History and Concurrent Conditions .................... 83

D.7.3 Concomitant Therapies ..................................................................................... 84

D.8.r Relevant Past Drug History (repeat as necessary) .............................................. 84

D.8.r.1 Name of Drug as Reported ............................................................................. 86

D.8.r.2 Medicinal Product Identifier (MPID) ............................................................ 86

D.8.r.3 Pharmaceutical Product Identifier (PhPID) ................................................. 87

D.8.r.4 Start Date ........................................................................................................ 87

D.8.r.5 End Date ......................................................................................................... 87

D.8.r.6 Indication (MedDRA code) ............................................................................. 88

D.8.r.7 Reaction (MedDRA code) ................................................................................ 88

D.9 In Case of Death ........................................................................................................ 89

D.9.1Date of Death ...................................................................................................... 89

D.9.2.r Reported Cause(s) of Death (repeat as necessary) ....................................... 89

D.9.2.r.1b Reported Cause(s) of Death (MedDRA code) ........................................... 89

D.9.2.r.2 Reported Cause(s) of Death (free text) ....................................................... 90

D.9.3 Was Autopsy Done? ........................................................................................... 90

D.9.4.r Autopsy-determined Cause(s) of Death (repeat as necessary) .................... 90

D.10 For a Parent-child / Foetus Report, Information Concerning the Parent ..... 92
D.10.1 Parent Identification ............................................................................................ 92

D.10.2 Parent Age Information ....................................................................................... 92

D.10.2.1 Date of Birth of Parent ................................................................................ 92

D.10.2.2 Age of Parent ................................................................................................ 93

D.10.3 Last Menstrual Period Date of Parent................................................................ 93

D.10.4 Body Weight (kg) of Parent ................................................................................. 93

D.10.5 Height (cm) of Parent ........................................................................................... 94

D.10.6 Sex of Parent ........................................................................................................ 94

ICH ICSR Implementation Guide 10 November 2016

-6-
 D.10.7 Relevant Medical History and Concurrent Conditions of Parent ..................... 94

D.10.7.1.r Structured Information of Parent (MedDRA code) (repeat as necessary) . 94

D.10.7.2 Text for Relevant Medical History and Concurrent Conditions of Parent ........... 96

D.10.8.r Relevant Past Drug History of Parent (repeat as necessary) ......................... 96

D.10.8.r.1 Name of Drug as Reported ........................................................................ 96

D.10.8.r.2 Medicinal Product Identifier (MPID) ....................................................... 97

D.10.8.r.3 Pharmaceutical Product Identifier (PhPID) ............................................ 97

D.10.8.r.4 Start Date ................................................................................................... 97

D.10.8.r.5 End Date .................................................................................................... 98

D.10.8.r.6 Indication (MedDRA code) ........................................................................ 98

D.10.8.r.7 Reactions (MedDRA code) ......................................................................... 99

E.i REACTION(S)/EVENT(S) (REPEAT AS NECESSARY) ...................... 100

E.i.1 Reaction / Event as Reported by the Primary Source ......................................... 101

E.i.1.1 Reaction / Event as Reported by the Primary Source in Native Language ........... 101

E.i.1.2 Reaction / Event as Reported by the Primary Source for Translation ...... 101

E.i.2.1 Reaction / Event (MedDRA code) ...................................................................... 102

E.i.3.1 Term Highlighted by the Reporter .................................................................... 102

E.i.3.2 Seriousness Criteria at Event Level (more than one can be chosen) .............. 102

E.i.3.2a Results in Death .......................................................................................... 103

E.i.3.2b Life Threatening .......................................................................................... 103

E.i.3.2c Caused / Prolonged Hospitalisation............................................................ 103

E.i.3.2d Disabling / Incapacitating ........................................................................... 103

E.i.3.2e Congenital Anomaly / Birth Defect ............................................................ 104

E.i.3.2f Other Medically Important Condition ........................................................ 104

E.i.4 Date of Start of Reaction / Event .......................................................................... 104

E.i.5 Date of End of Reaction / Event ........................................................................... 105

E.i.6 Duration of Reaction / Event ................................................................................ 105

E.i.7 Outcome of Reaction / Event at the Time of Last Observation .......................... 106

E.i.8 Medical Confirmation by Healthcare Professional ............................................. 106

E.i.9 Identification of the Country Where the Reaction / Event Occurred ................. 107

F.r Results of Tests and Procedures Relevant to the Investigation of the Patient (repeat as necessary) ..... 107

ICH ICSR Implementation Guide 10 November 2016

-7-
 F.r.1 Test Date ............................................................................................................... 108

F.r.2 Test Name.............................................................................................................. 108

F.r.2.1 Test Name (free text) .................................................................................... 108

F.r.2.2 Test Name (MedDRA code) .......................................................................... 109

F.r.3 Test Result ............................................................................................................. 109

F.r.3.1 Test Result (code) .......................................................................................... 109

F.r.3.2 Test Result (value / qualifier) ....................................................................... 110

F.r.3.3 Test Result (unit) .......................................................................................... 110

F.r.3.4 Result Unstructured Data (free text) .......................................................... 110

F.r.4 Normal Low Value ................................................................................................ 111

F.r.5 Normal High Value ............................................................................................... 111

F.r.6 Comments (free text) ............................................................................................ 111

F.r.7 More Information Available ................................................................................. 112

G.k DRUG(S) INFORMATION (REPEAT AS NECESSARY) .................... 113

G.k.1 Characterisation of Drug Role............................................................................. 115

G.k.2 Drug Identification ............................................................................................... 116

G.k.2.1 Medicinal Product Unique Identifier/Pharmaceutical Product Unique Identifier .. 117

G.k.2.2 Medicinal Product Name as Reported by the Primary Source.................. 118

G.k.2.3.r Substance / Specified Substance Identifier and Strength (repeat as necessary) ... 118

G.k.3 Holder and Authorisation / Application Number of Drug ................................. 121

G.k.3.1 Authorisation / Application Number .......................................................... 121

G.k.3.2 Country of Authorisation / Application ...................................................... 122

G.k.3.3 Name of Holder / Applicant ......................................................................... 122

G.k.4.r Dosage and Relevant Information (repeat as necessary)................................ 122

G.k.4.r.1a Dose (number) .......................................................................................... 123

G.k.4.r.1b Dose (unit) ................................................................................................ 123

G.k.4.r.2 Number of Units in the Interval ............................................................... 123

G.k.4.r.3 Definition of the Time Interval Unit ........................................................ 123

G.k.4.r.4 Date and Time of Start of Drug ................................................................ 124

G.k.4.r.5 Date and Time of Last Administration .................................................... 124

G.k.4.r.6 Duration of Drug Administration ............................................................. 124

ICH ICSR Implementation Guide 10 November 2016

-8-
 G.k.4.r.7 Batch / Lot Number ................................................................................... 125

G.k.4.r.8 Dosage Text ................................................................................................ 125

G.k.4.r.9 Pharmaceutical Dose Form ....................................................................... 127

G.k.4.r.10 Route of Administration .......................................................................... 128

G.k.4.r.11 Parent Route of Administration (in case of a parent child / foetus report) 129

G.k.5 Cumulative Dose to First Reaction ..................................................................... 130

G.k.6 Gestation Period at Time of Exposure ................................................................ 130

G.k.7.r Indication for Use in Case (repeat as necessary) ............................................ 131

G.k.7.r.1 Indication as Reported by the Primary Source........................................ 131

G.k.7.r.2 Indication (MedDRA code) ........................................................................ 131

G.k.8 Action(s) Taken with Drug .................................................................................. 132

G.k.9.i Drug-reaction(s) / Event(s) Matrix (repeat as necessary) ............................... 132

G.k.9.i.1 Reaction(s) / Event(s) Assessed ................................................................. 133

G.k.9.i.2 Assessment of Relatedness of Drug to Reaction(s)/Event(s) ..................... 134

G.k.9.i.3 Time Interval between Beginning of Drug Administration and Start of Reaction / Event 135

G.k.9.i.4 Did Reaction Recur on Re-administration? .............................................. 136

G.k.10.r Additional Information on Drug (coded) (repeat as necessary) .................... 136

G.k.11 Additional Information on Drug (free text) ...................................................... 137

H NARRATIVE CASE SUMMARY AND FURTHER INFORMATION .... 138

H.1 Case Narrative Including Clinical Course, Therapeutic Measures, Outcome and
Additional Relevant Information .................................................................................. 138

H.2 Reporter's Comments .............................................................................................. 139

H.3.r Sender's Diagnosis (MedDRA code) (repeat as necessary) ................................ 139

H.4 Sender's Comments ................................................................................................ 140

H.5.r Case Summary and Reporter’s Comments in Native Language (repeat as necessary) .... 140

H.5.r.1a Case Summary and Reporter’s Comments Text....................................... 140

H.5.r.1b Case Summary and Reporter’s Comments Language.............................. 140

3.5 DOCUMENT ATTACHMENTS ............................................................. 141

3.5.1 User Guidance ....................................................................................................... 141

3.5.2 Technical specification .......................................................................................... 141

3.5.3 Examples of XML instances ................................................................................. 142

ICH ICSR Implementation Guide 10 November 2016

-9-
4.0 THE ICSR ACKNOWLEDGEMENT TRANSACTION......................... 143
4.1 Acknowledgement Message in HL7 ........................................................................ 143

4.2 ICH ICSR Acknowledgement Message ................................................................... 143

ACK.M / A ICH ICSR Batch Acknowledgement ........................................ 145

ACK.M.1 Acknowledgement Batch Number ................................................................ 145

ACK.M.2 Acknowledgement Batch Sender Identifier ................................................. 145

ACK.M.3 Acknowledgement Batch Receiver Identifier............................................... 146

ACK.M.4 Acknowledgement Date of Batch Transmission .......................................... 146

ACK.A.1 ICSR Batch Number....................................................................................... 147

ACK.A.2 Acknowledgement Local Message Number .................................................. 147

ACK.A.3 Date of ICSR Batch Transmission ................................................................ 147

ACK.A.4 Transmission Acknowledgement Code ......................................................... 148

ACK.A.5 Batch Validation Error .................................................................................. 148

ACK.B ICH ICSR Message Acknowledgement .......................................... 148

ACK.B.r.1 ICSR Message Number ............................................................................... 148

ACK.B.r.2 Local Report Number .................................................................................. 148

ACK.B.r.3 ICSR Message ACK Receiver ...................................................................... 149

ACK.B.r.4 ICSR Message ACK Sender ........................................................................ 149

ACK.B.r.5 Date of ICSR Message Creation.................................................................. 149

ACK.B.r.6 Acknowledgement Code for a ICSR Message............................................. 150

ACK.B.r.7 Error / Warning Message or Comment....................................................... 150

APPENDICES ............................................................................................... 151

APPENDIX I – PREPARING AND SENDING ICH ICSRS: ..................... 151
Appendix I (A) – ICH ICSR SCHEMAs ........................................................................ 151

1. List of schemas for ICH ICSR messages and ICSR Acknowledgement messages ......... 151

2. User Guidance for each ICH ICSR schemas ....................................................... 152

Appendix I (B) – Backwards & Forwards Compatibility ............................................. 156

Appendix I (C) – Schema files ....................................................................................... 156

Appendix I (D) – Reference Instances for ICH ICSR message and ICSR Acknowledgement message156

Appendix I (E) – Example Instances of report cases ................................................... 156

Appendix I (F) – ICH E2B code lists ............................................................................. 157

ICH ICSR Implementation Guide 10 November 2016

-10-
 Appendix I (G) – Technical Information ....................................................................... 157

Appendix I (H) – SGML & XML conversion ................................................................. 157

APPENDIX II – DATE / TIME .................................................................. 158

Appendix II (A) Date / Time .......................................................................................... 158

Appendix II (B) Time Zone ............................................................................................ 159

Appendix II (C) ISO 8601 Compliant XML Examples ................................................. 159

APPENDIX III - ABBREVIATIONS and GLOSSARY OF TERMS ........... 160

Appendix III (A)ABBREVIATIONS .............................................................................. 160

Appendix III (B) GLOSSARY of TERMS ...................................................................... 162

ICH ICSR Implementation Guide 10 November 2016

-11-
Sections of this document referencing the ISO/HL7 standard ‘ISO/HL7 27953-2: 2011 Health
informatics -- Individual case safety reports (ICSRs) in pharmacovigilance -- Part 2: Human
pharmaceutical reporting requirements for ICSR’ are used with the publishers’ permission.
Copyright of the ISO/HL7 27953-2: 2011 standard is held jointly by ISO and Health Level
Seven International. ALL RIGHTS RESERVED.

ICH ICSR Implementation Guide 10 November 2016

-12-
Introduction
This document is a guide for implementing the standard adopted by the ICH 1 for electronic
transmission of Individual Case Safety Reports (ICSRs) according to the ICH E2B(R3) message
standard. This Implementation Guide (IG) was jointly developed by the ICH E2B(R3) and M2
Expert Working Groups (EWGs). The E2B(R3) EWG provided business requirements and the
M2 EWG provided technical content for this IG. These two EWGs were reconstituted as the
ICH E2B(R3) EWG in November 2010.

Conceptually, an ICSR is a report of information describing adverse event(s) / reaction(s)

experienced by an individual patient.

This ICH IG focuses on medicinal products and therapeutic biologics for human use. However,
the ICH is aware of other regional applications of the messaging standard that have a wider
scope, such as pharmacovigilance activities related to vaccines, herbal products, cosmetics,
veterinary products or medical devices. The primary ICH application is for the exchange of
pharmacovigilance information between and among the pharmaceutical industry and regulatory
authorities.

This IG is also intended to support the implementation of software and tools for creating,
editing, sending and receiving electronic ICSR messages.

This IG is not intended to serve as a reference for proper pharmacovigilance practices nor is it
intended to explain the underlying scientific or medical issues that support the collation,
categorisation or analysis of medicinal product safety information. It is also not intended to
explain the rationale that underlies proper case safety reporting.

The focus of this ICH IG is on technical implementation. Thus, the intended audience includes
system developers, IT professionals, system implementers and system users who need to
understand the technical requirements for constructing and using valid electronic messages to
transmit ICSRs. This IG provides the information necessary to support the development of
adequate informatics tools (e.g. forms and interfaces for end user data entry) as well as technical
requirements to design style sheets, conduct data transformations and code well-formed
messages. However, this IG does not provide or infer guidance or recommendations for any
particular database technology or software platform. Instead, this IG describes the technical
requirement to generate valid XML code according to the standard outlined in this IG.

Subsequent sections of this IG provide explanatory text concerning the business context for
electronic ICSR messaging, including ICH documentation, and application to
pharmacovigilance transactions.

1The International Council for Harmonisation of Technical Requirements for Pharmaceuticals

for Human Use (ICH) http://www.ich.org/

ICH ICSR Implementation Guide 10 November 2016

-13-
1.0 Purpose

The business objective of this ICH IG is to standardise the definitions of the data elements used
in the electronic transmission of different types of ICSRs, regardless of source and destination.
This IG describes data elements for ICSRs for both the pre- and post-authorisation periods, and
addresses both adverse drug reaction reports and adverse event reports. The technical objective
of this IG is to assist reporters and recipients (including pharmaceutical companies, regulatory
authorities and non-commercial sponsors) in implementing systems to construct transmittable
ICSR messages. The representation of the ICSR follows an international standard that is
platform-, application-, and vendor-independent.

1.1 Scope
The representation of the ICSR in this IG, in its format and content, is made up of a large
number of data elements, allowing precise reporting of medical content to most business
partners, including regulatory authorities. For example, the data elements and their format are
suitable to describe several types of case reports including those without adverse events or
adverse drug reactions, such as medicinal product administration during pregnancy, overdose,
medication error, or potential lack of efficacy. Therefore, in order to maintain the integrity and
usability of the standard, requests for inclusion of additional local data should not be necessary
and should be avoided as much as possible. The scope of this IG for the ICH E2B (R3) ICSR
does not include the definition of database structures, the design of a paper report form, quality
control/quality assurance aspects, or technical security issues.

1.2 Business Case

Because of national and international agreements, rules, regulations, and the protection of
patient safety, there is a need to expedite the exchange of safety information (e.g. ICSRs):
• from identified reporting sources to regulatory authorities and pharmaceutical companies;
• between regulatory authorities;
• between pharmaceutical companies and regulatory authorities;
• between pharmaceutical companies;
• from clinical investigators, via the sponsor of a clinical trial, to ethics committees; or
• from authorities to the World Health Organisation (WHO) Collaborating Centres for
International Drug Monitoring.
The exchange of safety information is based on paper-based formats (e.g. Yellow Cards,
CIOMS I forms, MedWatch forms, etc.) or electronic media (e.g. on-line access, tape, CD, etc).
Considering the large number of potential participants in a world-wide exchange of information,
there should be a standard format that is capable of accommodating direct database-to-database
transmission using standardised message transfers. Successful electronic transmission of
information relies on the consistent and uniform interpretation of definitions for common data
elements and standard transmission procedures, such as those provided in this document.

ICH ICSR Implementation Guide 10 November 2016

-14-
Over the last decade as the number of case reports has increased, exchange of ICSRs has
increasingly shifted from paper-based to electronic reports and electronic transmission of case
safety information has become an important component of global pharmacovigilance. The ICH
released a consensus electronic standard for ICSRs in 1997 and this standard has undergone a
number of revisions since it was first adopted. The ICH E2B(R2) standard has been used for
regulatory compliance purposes for several years and, indeed, is now mandatory in some ICH
regulatory jurisdictions and is widely accepted.

Development of the standard described in this IG represents a change of the ICH process, as the
messaging standard was developed through a partnership with external Standards Development
Organisations (SDOs).Prior to the message standard described in this IG, ICH electronic
messaging standards were developed by the ICH M2 EWG for Electronic Standards for the
Transmission of Regulatory Information(ESTRI).Specifically, the current message standard was
developed through a collaborative relationship between the ICH and the Joint Initiative Council
(JIC); the JIC is a partnership of the International Organisation for Standardisation (ISO), the
Health Level Seven (HL7), the European Committee for Standardisation (CEN), the Clinical
Data Interchange Standards Consortium (CDISC), the International Health Terminology
Standards Development Organisation (IHTSDO), and GS1 2. The ICSR standard named ‘ISO /
HL7 27953-2: 2011 Health informatics -- Individual case safety reports (ICSRs) in
pharmacovigilance -- Part 2: Human pharmaceutical reporting requirements for ICSR’ is
available at the ISO website (http://www.iso.org/iso/store.htm).

2.0 BACKGROUND

2.1 General Background and History of ICH

2.1.1 The ICH and its Partners

The ICH brings together regulatory authorities and the pharmaceutical industry to harmonise
scientific and technical aspects of drug registration.
Further information about ICH and its work products is available from the ICH website.

2.1.2 History of ICH ICSR guidelines

The first ICH E2B guideline, Data Elements for Transmission of Individual Case Safety
Reports, was endorsed on July 17, 1997.It was modified in November 2000, and then published
with minor editorial changes in February 2001 as the ICH Step 4 E2B (M) guideline. As part of
an ICH document management initiative, the Step 4 E2B (M) guideline was retitled as the E2B
(R2) guideline in May 2005; there was no change in business content. The ICH M2 EWG
prepared the Electronic Transmission of Individual Case Safety Reports Message Specification

2GS1 is an international not-for-profit association dedicated to the design and implementation of

global standards and solutions to improve the efficiency and visibility of supply and demand
chains globally and across sectors.

ICH ICSR Implementation Guide 10 November 2016

-15-
guideline in 2001 to standardise the data elements for the electronic transmission of ICSRs by
identifying and defining the core elements for an ICSR, regardless of source or destination.

2.1.3 The Process of Revision in ICH

Considering the high volume of data and the large number of potential participants involved
with the world-wide exchange of safety information, there is an ongoing need for efficient
transmission of safety reports in a format that can be generated and processed nearly
automatically by a transactional database. This need has led to periodic revisions of the E2B
document, as described in Section 2.1.2 (above). The E2B(R3) message represents an iteration
of the electronic ICSR that has evolved in a controlled fashion over more than a decade.

Successful electronic transmission of ICSRs relies on standard common data elements and
syntactical definition of the electronic message. Therefore, the adoption of a standardised
electronic message across regions, regulatory agencies, and other participants is of paramount
importance. In 2006, the ICH decided to pursue an alternative model for the development of the
third revision of E2B that engaged SDOs. This IG describes the messaging standard for the
implementation of the E2B(R3) message developed through this new process.

In order to broaden the ICH’s outreach and be able to develop a global, harmonised and
implementable electronic messaging standard, the ICH Steering Committee, which is the body
that governs the ICH, made a decision to align its development efforts with SDOs. The ISO,
HL7, CEN, CDISC and IHTSDO, along with their respective technical committees (TCs) and
stakeholders for health informatics standardisation, have collectively identified an opportunity
to collaborate, coordinate, and cooperate so their efforts will support the creation of global
electronic health informatics standards that can be integrated into the broader healthcare
environment.

To that end, the SDOs noted above have formed a Joint Initiative to address and resolve issues
of gaps, overlaps, and counter-productive standardisation efforts through an agreed-upon
decision process. Governance of the Joint Initiative is via a Joint Initiative Council (JIC), which
has representation from each member SDO. This approach facilitates a single best standard for
each problem with mutual recognition and endorsement of standards by participating SDOs.
For the ICH, working with SDOs to leverage resources for electronic standards development
and avoid overlapping, counter-productive, or counter-acting standards is critical to achieving
and maintaining its own harmonisation goals.

2.2 Development of ICSR Standard under Joint Initiative

The ICH’s original New Work Item Proposal to ISO for the ICSR standard was accepted as an
ISO Project activity, ISO 27953, and was subsequently endorsed as a Joint Initiative project in
February 2008. The ICSR standard was considered a candidate for SDO harmonisation because
of global interest in improving patient safety through the electronic exchange of unambiguous,
structured data to support regulatory and patient safety needs.

ICH ICSR Implementation Guide 10 November 2016

-16-
The ISO 27953 consolidates content and messaging specifications based on ISO New Work
Item Proposal N545 (Pharmacovigilance - Structure and Data Elements of Individual Case
Safety Report), HL7 ICSR Release 1 Normative Standard, and HL7 ICSR Release 2 Draft
Standard for Trial Use (DSTU). The ICSR standard was developed through the ISO ballot
process, Draft International Standard, Final Draft International Standard, and International
Standard (IS). The standard was published by ISO as the IS in November 2011.

2.3 Background of Message Standard

The HL7 version 3 (V3) messaging standard deals with a static model of health care information
as viewed within the scope of HL7 standards development activities. ISO recognises HL7 as an
accredited partnering organisation for mutually issuing standards. The first mutually published
standard was ISO/HL7 21731:2006 Health informatics -- HL7 version 3 -- Reference

Information Model -- Release 1. 3 HL7 V3 was developed to address the complex needs of
health information technology. The HL7 Reference Information Model (RIM) is the
cornerstone of HL7 V3 and the essential model from which all HL7 messages are derived. The
RIM defines data content needed in a specific context and provides an explicit representation of
the semantic and lexical connections that exist between the information carried in the elements
of a message. HL7 V3 supports development of specifications that facilitate interoperability
between systems. 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. To learn more about HL7 V3, refer to ‘Understanding
Version 3: A primer on the HL7 Version 3 Healthcare Interoperability Standard – Normative
Edition,’ by Andrew Hinchley. The 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.

A framework of ICSR standard published as ‘ISO / HL7 27953-1:2011 Health informatics --

Individual case safety reports (ICSRs) in pharmacovigilance -- Part 1: Framework for adverse
event reporting’ supports message transmissions in drugs, medical devices, veterinary drugs,
cosmetic, and dietary supplements. 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 sub-
set’ of the standard supporting electronic messaging for the ICH E2B(R3) data elements.
Although this standard is the ‘ICH sub-set’, it can be applied to regions and business cases
beyond the narrower use described in this ICH E2B(R3)IG. Elements of the ISO / HL7 27953-2
standard which solely relate to use cases outside the remit of ICH will not be addressed within
this document. Detailed information about ISO/HL7 27953-2 can be obtained from ISO web
site: http://www.iso.org/iso/home/store.htm.

3 Available from the HL7 Website, at http://www.hl7.org

ICH ICSR Implementation Guide 10 November 2016

-17-
2.4 Representation of the Electronic ICSR

2.4.1 Why Standardisation and Electronic ICSR Exchange are 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.

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.

2.4.2 How ICSRs Are Presently Transmitted and the Advantages of Electronic
Submissions

To support the ICH E2B guideline, the ICH M2 EWG published the ‘Electronic Transmission
of Individual Case Safety Reports Message Specification (ICH ICSR DTD Version 2.1), Final
Version 2.3’ in February of 2001. At that time, prior work on the standardisation of an
electronic message by HL7 and EDIFACT (Electronic Data Interchange for Administration,
Commerce and Transport) was considered, but the ICH selected SGML (Standard Generalised
Markup Language, ISO 8879:1986) as the preferred alternative because SGML was the de facto
standard for the interchange of information. SGML also supported the multi-lingual character
sets needed across ICH regions.

In spite of this fact, the SGML-based DTD (Document Type Definition) approach is no longer
the optimal solution. As a result, the current messaging standard herein now relies upon XML
schemas. The reasoning is explained below.

ICH ICSR Implementation Guide 10 November 2016

-18-
2.4.2.1 Markup Languages 4

First published in 1988, Standard Generalised Markup Language (SGML) is an ISO standard
(ISO 8879) designed to describe the structure and content of electronic documents, with an
original purpose of enabling the exchange of electronic documents between business entities
that need information to be available for extended periods of time (archived).It serves as a basis
for eXtensibleMarkup Language (XML), which is simpler than SGML yet maintains the most
useful parts of SGML.

SGML requires that structured documents reference a Document Type Definition (DTD) to be
valid. The DTD is the tool used to create and describe the expected SGML or XML. Simply, a
DTD specifies the syntax (the elements, attributes, entities, and notations) required in a
document authored in SGML or XML. Once a DTD is created and a document is written based
on that DTD, the document is then compared to the DTD. This is referred to as validation. If
the document follows the rules listed in the DTD, then the document is said to be valid.
SGML/XML documents that do not follow the rules in their DTDs are categorised as invalid.

The DTD specifies the required structure and format of a particular document.XML is more
flexible than SGML and allows for the concept of ‘well-formed’ data – content that meets the
basic vocabulary and ‘grammatical’ requirements of XML but does not reference a DTD for a
specific set of attributes or list of required elements.XML contains a further concept called a
schema. An XML schema introduces both the ability to apply more complex constraints and the
ability to have more flexibility in well-formed data.

In general, DTDs perform well when applied to documents or text-intensive information.XML

schema work best for data-intensive information 5. One challenge with DTDs is that they
represent two different things at the same time: a grammar and a schema. Because XML syntax
is ‘fixed’, it does not need ‘grammar’ to properly access the information content. In addition,

XML schemas can be manipulated, stored, and indexed, which is a practical advantage 6.

4‘Co-existence of Traditional EDI with XML-EDI’, Skip Stein, Management Systems

Consulting, Inc., http://www.msc-inc.net/
5Tittel, Ed, Pitts, Natanya, and Boumphrey, Frank.XML for Dummies. New York: Wiley

Publishing, Inc., 2002.

6‘Beyond the SGML DTD’, François CHAHUNEAU, Directeur Général/General Manager,

AIS S.A., 15-17 rue Rémy Dumoncel, 75014, Paris, FRANCE,

http://xml.coverpages.org/chahuneauXML.html

ICH ICSR Implementation Guide 10 November 2016

-19-
Another advantage to XML is that Unicode is universally present in all XML parsers. Except

for more recent ones, most SGML parsers do not provide Unicode support 7. Unicode provides
a ‘unique’ code (a number) for each character. Thus, characters are represented in an abstract
way while the visual rendering (size, shape, font or style) is left to other applications, such as a
web browser or word processor. In this way, translation between languages is built into the use

of XML 8.

2.4.2.2 Advantages to Electronic Submissions

The ICH chose to adopt an XML schema for the ICSR as it is more suitable for the intended
purpose: XML is portable and non-proprietary. It can be used to store and share information
electronically across platforms. XML is used for encapsulating information to be passed
between two computing systems which might otherwise be unable to communicate. It provides
a common envelope for inter-process communication (messaging). It is supported by an

international standard and will, therefore, remain accessible 9.

The ICH ICSR enhances electronic adverse event reporting and analysis by facilitating the
efficient reporting of suspected product-related adverse events/reactions. The electronic
environment:
• improves the ability to efficiently exchange and process ICSR data;
• facilitates the transfer of information to organisations who need it;
• enables incoming messages to be automatically routed and processed;
• facilitates aggregation of safety data for analysis; and
• allows minimising resources required for data (re-)entry activities.

3.0 ESSENTIAL COMPONENTS

Developing software specifications to support business needs, such as those specified in

E2B(R3), calls for an approach where the functional and procedural requirements are well
understood and reflected accurately in the electronic message. The electronic message must not
only contain an accurate definition of the data elements (XML schema), but also maintain any
required relationships between the elements for efficient information exchange. The
development of relational diagrams, attribute lists, numeric codes, and a constrained ICH ICSR
schema are all parts of the process of developing the software specifications to facilitate
electronic transmission of ICSRs. The ICH ICSR message allows for the preparation of adverse

7‘XML: What HTML Wanted to Be!’, Norma Haakonstad, National Accounts Manager,
Arbortext, Inc., 1000 Victors Way, Ann Arbor (Michigan) 48108
8‘Unicode’.Wikipedia<http://en.wikipedia.org/wiki/Unicode>, 18SEP2008.
9 The XML FAQ, Version 4.56 (8 August 2007), Edited by Peter Flynn, Frequently-Asked

Questions about the Extensible Markup Language, http://xml.silmaril.ie/

ICH ICSR Implementation Guide 10 November 2016

-20-
event/reaction data sets that can accurately maintain and represent the intended purpose of the
E2B(R3) document. Section 3 of this IG lists the exact E2B(R3) data elements and essential
components to develop usable and exchangeable ICH ICSR messages. Necessary schemas for
the ICH ICSR message are listed in Appendix I (A).

3.1 ICH ICSR Relational Diagrams

Figure 1 below illustrates the relationship between the main sections defined in E2B(R3) for the
ICH ICSR message and XML descriptors. Each box in the diagram represents a related section
of the E2B(R3) data element structure, and all the data elements in that block are listed in the
attribute list (Section 3.4).For example, box C.1 in the diagram Identification of the Case Safety
Report represents the complete C.1 section of the E2B(R3) data elements and the C.1 block of
elements listed in the ICH E2B(R3) data element list.

The E2B(R3) specification defines inter-relationships between data elements allowing for
various mandatory/required, optional, unique, or repeatable sections (information
blocks).Relationships between elements vary, as indicated by:

• 1 ..1 (unique and mandatory);

• 0 ..1 (unique and optional);
• 1 ..n (one to many and mandatory); or
• 0 ..n (one to many and optional).

Diagrams in Section 3.4 provide the next level of detail and are intended to help business users
understand how the various portions of the ICSR relate to one another, while helping
application developers understand how to populate an XML message designed and developed to
meet the E2B(R3) specification.

ICH ICSR Implementation Guide 10 November 2016

-21-
Figure 1: The ICH ICSR Structure

The ICH ICSR

C.1 D
Identification of the Case Safety Report 1…1 1…1 Patient characteristics

C.2.r E.i
Primary source(s) of information 1…n 1…n Reaction(s) / Event(s)

C.3 F.r
Information on Sender of Case Safety Results of tests and procedures relevant
Report 1…1 0…n to the Investigation of the Patient

C.4.r G.k
Literature Reference(s) 0…n 1…n Drug(s) Information

H
C.5
Narrative Case Summary and Further
Study Identification 0…n 1…1 Information

Legend
1 to Many (1...n)
Mandatory

1 to 1
Mandatory

1 to Many (0...n)
Optional

1 to 1 (0...1)
Optional

ICH ICSR Implementation Guide 10 November 2016

-22-
3.2 Code Sets, Terminologies and Vocabularies for E2B(R3)
There are several terminologies and controlled vocabularies that are used to describe or code
information within an ICSR. Some of these terminologies or code sets are general and are used
by many applications, such as units for mass or time, or country codes. Others are specific to
the medical section, such as MedDRA (Medical Dictionary for Regulatory Activities).Still
others are specific code lists created for the ICH. This section will address the code sets,
terminologies and vocabularies used in this IG. Specific guidance is provided in Section 3.4 for
each individual element.

Although the technical specifications for the code sets (e.g. Data Types) are provided in Section
3.4, these are current as of printing this IG. Specifications may evolve over time to adapt to
new technologies and new business needs. Ultimately, the validation specifications of code sets
(e.g. technical format and values allowed) are defined by the organisation that maintains the
terminology, and those organisations should be consulted to obtain the most current
specifications for their code sets.

Code set specifications (e.g. technical format and values allowed) are defined by the
organisation that maintains the terminology. As they may evolve at a different pace
than the publication of this IG, those organisations should be consulted to obtain
their most current specifications.

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 the
branch ‘joint-iso-itu-t.country.us.organisation.hl7.external-code-system.MedDRA’.

Organizations can obtain an OID by requesting an identifier from a registrar, and, if it desires,
an organisation can in turn become a registrar and subsequently generate child OIDs to its
internal objects. The ICH is implementing OIDs to identify code systems used in ICSR
message exchange.

Tables 1 through 7 in this section of the IG list all the OIDs used to code the data elements of
the ICH ICSR. A list of OIDs registered by ICH is available on the ICH website. In addition to
OIDs in the tables 1 to 7, some OIDs registered by HL7 are used in ICSR messages to
differentiate the intended use of some elements (e.g. in data elements F.r.4 and F.r.5 for normal
values of test results, different OIDs are used to differentiate between ‘low’ and ‘high’,
respectively).Although those HL7 registered OIDs are not described in the tables below, the
reference instance in Appendix I (D) provides all OIDs in the context they are used.

3.2.1 Terminologies and Vocabularies Employed by the ICSR Message

ICH ICSR Implementation Guide 10 November 2016

-23-
3.2.1.1 ISO Identification of Medicinal Products (IDMP)

In collaboration with ICH, ISO developed a set of standards to enhance exchange of information
for medicinal products. These include identifiers to allow mapping of international
terminologies for routes of administration, dosage forms and units of measurement, as well as
controlled identifiers to enable cross-border identification of pharmaceutical products and
mapping to their core components, e.g. substances.

The ISO IDMP standards include:

• ISO 11238 Health informatics － Identification of medicinal products－Data elements and
structures for the unique identification and exchange of regulated information on
substances
• ISO 11239 Health Informatics － Identification of medicinal products －Data elements and
structures for the unique identification and exchange of regulated information on
pharmaceutical dose forms, units of presentation, routes of administration and packaging
• ISO 11240 Health informatics － Identification of medicinal products －Data elements and
structures for the unique identification and exchange of units of measurement
• ISO 11615 Health Informatics －Identification of medicinal products – Data elements and
structures for the unique identification and exchange of regulated medicinal product
information
• ISO 11616 Health informatics － Identification of medicinal products－Data elements and
structures for the unique identification and exchange of regulated pharmaceutical product
information

The data elements that use ISO IDMP vocabularies are described in Section 3.4 of this
document. However, where the ISO IDMP terms and/or identifiers (e.g. codes) are not
available, the IG provides instructions for alternate means to code the information.

Until the controlled vocabularies for the ISO IDMP are available, temporary rules
are applied to the data elements. Terms and identifiers (codes) may be provided by
each region until the ISO IDMP controlled vocabularies are implemented.

ICH ICSR Implementation Guide 10 November 2016

-24-
Table 1: E2B (R3) data elements and IDMP OIDs
Element id Element Name OID Reference 10
D.8.r.2b Medicinal Product Identifier (MPID) ISO11615 MPID
D.8.r.3b Pharmaceutical Product Identifier (PhPID) ISO11616 PhPID
D.10.8.r.2b Medicinal Product Identifier (MPID) ISO11615 MPID
D.10.8.r.3b Pharmaceutical Product Identifier (PhPID) ISO11616 PhPID
G.k.2.1.1b Medicinal Product Identifier (MPID) ISO11615 MPID
G.k.2.1.2b Pharmaceutical Product Identifier (PhPID) ISO11616 PhPID
ISO11238 IDMP
G.k.2.3.r.2b Substance/Specified Substance TermID
Substance
ISO11239 IDMP Dosage
G.k.4.r.9.2b Pharmaceutical Dose Form TermID
Forms & Routes of Admin
ISO11239 IDMP Dosage
G.k.4.r.10.2b Route of Administration TermID
Forms & Routes of Admin
ISO11239 IDMP Dosage
G.k.4.r.11.2b Parent Route of Administration TermID
Forms & Routes of Admin

3.2.1.2 MedDRA - the Medical Dictionary for Regulatory Activities

MedDRA® - the Medical Dictionary for Regulatory Activities - is a medical terminology used to
classify adverse event information associated with the use of biopharmaceuticals and other
medical products (e.g. medical devices and vaccines). Coding these data to a standard set of
MedDRA terms allows health authorities and the biopharmaceutical industry to more readily

exchange and analyze data related to the safe use of medical products 11.

MedDRA trademark is owned by the International Federation of Pharmaceutical

Manufacturers and Associations (IFPMA) on behalf of ICH, and MedDRA was developed by
the ICH. The MSSO - Maintenance and Support Services Organization - serves as the
repository, maintainer, and distributor of MedDRA as well as the source for the most up-to-date
information regarding MedDRA and its application within the biopharmaceutical industry and
regulators. MedDRA subscribers submit proposed changes to the terminology. The MSSO
includes a group of internationally based physicians who review all proposed subscriber
changes and provide a timely response directly to the requesting subscriber.
The ICH ICSR utilises MedDRA to code a number of medical concepts, such as adverse
reactions or events, indications for drug use, medical history, etc. The following elements
require MedDRA coding at the Lowest Level Term (LLT).Please note that only one version of
MedDRA can be used in a single ICSR.

10These will be replaced with the registered OID reference when it is available.
11This description of MedDRA is taken from the webpage of the MSSO at
http://www.meddramsso.com/. For more information please see webpage for ICH.

ICH ICSR Implementation Guide 10 November 2016

-25-
Table 2: E2B (R3) data elements and MedDRA OIDs
Element id Element Name OID Reference
Medical History (disease / surgical
D.7.1.r.1b 2.16.840.1.113883.6.163
procedure / etc.) (MedDRA code)
D.8.r.6b Indication (MedDRA code) 2.16.840.1.113883.6.163
D.8.r.7b Reaction (MedDRA code) 2.16.840.1.113883.6.163
Reported Cause(s) of Death
D.9.2.r.1b 2.16.840.1.113883.6.163
(MedDRA code)
Autopsy-determined Cause(s) of
D.9.4.r.1b 2.16.840.1.113883.6.163
Death (MedDRA code)
Medical History (disease / surgical
D.10.7.1.r.1b 2.16.840.1.113883.6.163
procedure / etc.) (MedDRA code)
D.10.8.r.6b Indication (MedDRA code) 2.16.840.1.113883.6.163
D.10.8.r.7b Reactions (MedDRA code) 2.16.840.1.113883.6.163
E.i.2.1b Reactions / Event (MedDRA code) 2.16.840.1.113883.6.163
F.r.2.2b Test Name (MedDRA code) 2.16.840.1.113883.6.163
G.k.7.r.2b Indication (MedDRA code) 2.16.840.1.113883.6.163
Sender's Diagnosis / Syndrome and /
H.3.r.1b or Reclassification of Reaction / Event 2.16.840.1.113883.6.163
(MedDRA code)

ICH ICSR Implementation Guide 10 November 2016

-26-
3.2.2 ICH Maintained Code Sets and Object Identifiers (OIDs) Created for the ICH ICSR

This section contains tables of Code Sets and OIDs relevant to this IG specifically created for
the ICH; these code sets are maintained by or for ICH.

Table3: E2B (R3) data elements and ICH ICSR message Codes OIDs

Element id Element Name ICH OID

N.1.1 Type of Messages in Batch 2.16.840.1.113883.3.989.2.1.1.1
C.1.3 Type of Report 2.16.840.1.113883.3.989.2.1.1.2
C.1.8.2 First Sender of This Case 2.16.840.1.113883.3.989.2.1.1.3
C.1.11.1 Report Nullification / Amendment 2.16.840.1.113883.3.989.2.1.1.5
C.2.r.4 Qualification 2.16.840.1.113883.3.989.2.1.1.6
C.3.1 Sender Type 2.16.840.1.113883.3.989.2.1.1.7
Study Type Where Reaction(s) /
C.5.4 2.16.840.1.113883.3.989.2.1.1.8
Event(s) Were Observed
D.1.1.1 – Source(s) of the Patient Medical
2.16.840.1.113883.3.989.2.1.1.4
D.1.1.4 Record Number
D.2.3 Patient Age Group (as per reporter) 2.16.840.1.113883.3.989.2.1.1.9
E.i.3.1 Term Highlighted by the Reporter 2.16.840.1.113883.3.989.2.1.1.10
Outcome of Reaction / Event at the
E.i.7 2.16.840.1.113883.3.989.2.1.1.11
Time of Last Observation
F.r.3.1 Test Result (code) 2.16.840.1.113883.3.989.2.1.1.12
G.k.1 Characterisation of Drug Role 2.16.840.1.113883.3.989.2.1.1.13
G.k.4.r.10.2b, Route of Administration TermID
2.16.840.1.113883.3.989.2.1.1.14
G.k.4.r.11.2b (E2B(R2))
G.k.8 Action(s) Taken with Drug 2.16.840.1.113883.3.989.2.1.1.15
Did Reaction Recur on Re-
G.k.9.i.4 2.16.840.1.113883.3.989.2.1.1.16
Administration?
Additional Information on Drug
G.k.10.r 2.16.840.1.113883.3.989.2.1.1.17
(coded) (repeat as necessary)

ICH ICSR Implementation Guide 10 November 2016

-27-
Table4: E2B (R3) data elements and ICH ICSR message Codes OIDs (ICH constrained
UCUM codes)

Element id Element Name ICH OID

Age at Time of Onset of Reaction /
D.2.2b 2.16.840.1.113883.3.989.2.1.1.26
Event (unit)
Gestation Period When Reaction /
D.2.2.1b Event Was Observed in the Foetus 2.16.840.1.113883.3.989.2.1.1.26
(unit)
D.10.2.2b Age of Parent (unit) 2.16.840.1.113883.3.989.2.1.1.26
E.i.6b Duration of Reaction / Event (unit) 2.16.840.1.113883.3.989.2.1.1.26
G.k.2.3.r.3b Strength (unit) 2.16.840.1.113883.3.989.2.1.1.25
G.k.4.r.1b Dose (unit) 2.16.840.1.113883.3.989.2.1.1.25
G.k.4.r.3 Definition of the Time Interval Unit 2.16.840.1.113883.3.989.2.1.1.26
Duration of the Drug Administration
G.k.4.r.6b 2.16.840.1.113883.3.989.2.1.1.26
(unit)
Cumulative Dose to First Reaction
G.k.5b 2.16.840.1.113883.3.989.2.1.1.25
(unit)
Gestation Period at Time of Exposure
G.k.6b 2.16.840.1.113883.3.989.2.1.1.26
(unit)
Time Interval between Beginning of
G.k.9.i.3.1b Drug Administration and Start of 2.16.840.1.113883.3.989.2.1.1.26
Reaction / Event (unit)
Time Interval between Last Dose of
G.k.9.i.3.2b Drug and Start of Reaction / Event 2.16.840.1.113883.3.989.2.1.1.26
(unit)

There is an exception for F.r.3.3 ‘Test Result’. ICH does not provide constrained UCUM
codes for this field to allow variety of units. UCUM codes can be selected from the original
UCUM list and OID is listed in the table 8.

ICH ICSR Implementation Guide 10 November 2016

-28-
Table5: E2B (R3) data elements and ICSR message Namespace OIDs

Element id Element Name ICH OID

N.1.2 Batch Number 2.16.840.1.113883.3.989.2.1.3.22
N.1.3 Batch Sender Identifier 2.16.840.1.113883.3.989.2.1.3.13
N.1.4 Batch Receiver Identifier 2.16.840.1.113883.3.989.2.1.3.14
N.2.r.2 Message Sender Identifier 2.16.840.1.113883.3.989.2.1.3.11
N.2.r.3 Message Receiver Identifier 2.16.840.1.113883.3.989.2.1.3.12
Sender’s (case) Safety Report
C.1.1 2.16.840.1.113883.3.989.2.1.3.1
Unique Identifier
Worldwide Unique Case
C.1.8.1 2.16.840.1.113883.3.989.2.1.3.2
Identification Number
Source(s) of Case Identifier
C.1.9.1.r.1,
(repeated as necessary) and Case 2.16.840.1.113883.3.989.2.1.3.3
C.1.9.1.r.2
Identifier(s)
C.5.1.r.1 Study Registration Number 2.16.840.1.113883.3.989.2.1.3.6
C.5.3 Sponsor Study Number 2.16.840.1.113883.3.989.2.1.3.5
Patient Medical Record
D.1.1.1 2.16.840.1.113883.3.989.2.1.3.7
Number(s)(GP)
Patient Medical Record
D.1.1.2 2.16.840.1.113883.3.989.2.1.3.8
Number(s)(Specialist)
Patient Medical Record
D.1.1.3 2.16.840.1.113883.3.989.2.1.3.9
Number(s)(Hospital)
Patient Medical Record Number(s)
D.1.1.4 2.16.840.1.113883.3.989.2.1.3.10
(Investigation)
G.k.3.1 Authorisation / Application Number 2.16.840.1.113883.3.989.2.1.3.4

Table6: E2B (R3) data elements and Ack message Namespace OIDs

Element id Element Name ICH OID

Acknowledgement Batch Sender
ACK.M.2 2.16.840.1.113883.3.989.2.1.3.17
Identifier
Acknowledgement Batch Receiver
ACK.M.3 2.16.840.1.113883.3.989.2.1.3.18
Identifier
ACK.B.r.3 ICSR Message ACK Receiver 2.16.840.1.113883.3.989.2.1.3.16
ACK.B.r.4 ICSR Message ACK Sender 2.16.840.1.113883.3.989.2.1.3.15

ICH ICSR Implementation Guide 10 November 2016

-29-
Table7: ICSR / Ack common technical OIDs
Technical Codes ICH OID
Action Performed Code 2.16.840.1.113883.3.989.2.1.1.18
Observation Identification Codes 2.16.840.1.113883.3.989.2.1.1.19
Value Grouping Code 2.16.840.1.113883.3.989.2.1.1.20
Role of Assigned Entity Code 2.16.840.1.113883.3.989.2.1.1.21
Report Relationship Code 2.16.840.1.113883.3.989.2.1.1.22
Report Characterisation Codes 2.16.840.1.113883.3.989.2.1.1.23
Attention Line Codes 2.16.840.1.113883.3.989.2.1.1.24
Documentation & Reference Organiser Code 2.16.840.1.113883.3.989.2.1.1.27

3.2.3 International Standard Code Sets

This section contains information on Code Sets and OIDs relevant to this IG but not specifically
created by or for ICH. These code sets are maintained internationally in various places by
organisations and entities other than ICH.As such, the value and format allowed is limited to
what is defined by the organisation that maintains the code in question.
The external code sets and OIDs used in the message include:
• ISO 3166 Part 1 (alpha-2) －Codes for the representation of names of countries and their
subdivisions－ Part 1: Country codes, defines codes for the names of countries, dependent
territories, and special areas of geographical interest (2-letter codes)
• ISO 5218 －Information technology －Codes for the representation of human sexes
• ISO 639-2 －Codes for the Representation of Names of Languages

• UCUM－The Unified Code for Units of Measure (UCUM), case sensitive form 12

The following table lists the ICSR elements using these external code sets:

12More information on UCUM at http://unitsofmeasure.org/

The UCUM standard can be downloaded in xml or html form from
http://unitsofmeasure.org/trac/

ICH ICSR Implementation Guide 10 November 2016

-30-
Table8: International Standard Code Set OIDs

Coding
Element id Element Name Scheme OID Reference
Name
ISO 3166
C.2.r.3 Reporter's Country Code Part 1 1.0.3166.1.2.2
(alpha-2)
ISO 3166
C.3.4.5 Sender's Country Code Part 1 1.0.3166.1.2.2
(alpha-2)
ISO 3166
C.5.1.r.2 Study Registration Country Part 1 1.0.3166.1.2.2
(alpha-2)
D.5 Sex ISO 5218 1.0.5218

D.10.6 Sex of Parent ISO 5218 1.0.5218

ISO 639-
Reaction / Event as Reported by
E.i.1.1b 2/RA 1.0.639.2
the Primary Source Language
(alpha-3)
ISO 3166
Identification of the Country Where
E.i.9 Part 1 1.0.3166.1.2.2
the Reaction / Event Occurred
(alpha-2)
F.r.3.3 Test Result (unit) UCUM 2.16.840.1.113883.6.8
ISO 3166
Identification of the Country Where
G.k.2.4 Part 1 1.0.3166.1.2.2
the Drug Was Obtained (alpha-2)
ISO 3166
Country of Authorisation /
G.k.3.2 Part 1 1.0.3166.1.2.2
Application
(alpha-2)
ISO 639-
Case Summary and Reporter’s
H.5.r.1b 2/RA 1.0.639.2
Comments Language
(alpha-3)

There is one exception not included in the table above. The identifier used in the ‘Sender's
(case) Safety Report Unique Identifier’ (C.1.1) and the ‘Worldwide Unique Case Identification
Number’ (C.1.8.1), is not listed as it is not exclusively coded using ISO 3166 Part
1.Nevertheless, it does reference the ISO Country Code system in its construction; see the user
guidance for C.1.1 for more details.

3.2.3.1 Use of ISO 3166 Country Codes

Multiple data elements within the ICSR identify countries, either in relation to the drug, the
event, the sender or the reporter.E2B (R3) references ISO 3166-1 alpha-2, in the data elements
which capture country codes.

ICH ICSR Implementation Guide 10 November 2016

-31-
3.2.3.2 Use of message encoding

ICH M2 recommends to use UTF-8 for XML message encoding in all messages developed
based on ICH electronic guidelines.

3.3 ICH E2B(R3) Specifications for the Transmission of ICSRs

The E2B(R3) specification has a detailed breakdown of each data element in the ICH ICSR, as
well as notes on transmission and user guidance information.

3.3.1 Minimum Information

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.
Note: Additional validation rules for the required ‘minimal information’ might exist at the
regional level.

Any one of several data elements is sufficient to define an identifiable patient (e.g.
initials, age, and sex) or an identifiable reporter (e.g. initials, address, and
qualification). The guideline ICH E2D Section 5.1
(http://www.ich.org/products/guidelines/efficacy/article/efficacy-guidelines.html)
provides further guidance on this topic. It is also recognised that the patient and the
reporter can be the same individual and still fulfil the minimum reporting criteria.
Due to data privacy legislation in some countries, the patient’s initials and other
patient identifiers might not be exchanged between countries. However, at least one
of the data elements in the section D.1 must be populated and user guidance for this
data element is provided.

3.3.2 Definition of Data Elements within a Message

The guidance for transmitting ICSR information includes provisions for transmitting all relevant
data useful to assess an individual adverse event/reaction report. The message standard from
which this guidance is derived is fully capable of conveying a comprehensive ICSR. However,
it is noted that each and every data element will not be available for each and every
transmission.

In fact, for 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

ICH ICSR Implementation Guide 10 November 2016

-32-
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.

Furthermore, in addition to the minimum information required for an ICSR report (See Section
3.3.1) 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).

3.3.3 General Principles

While complete information is desirable, a minimum set of information is always required for
an ICSR to be valid. This applies to all types of ICSRs including initial case reports, follow-up
information, and cases to be amended or nullified.

All the information available should be reported 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), and ISO IDMP (see Section
3.2.1.1 for details). Please refer to each standard for further information.

Although the exchange of other unstructured data (e.g. published articles, full clinical records,
X-Ray images, etc.) is outside the scope of this IG, the technical solution to transmit
attachments is provided in Section 3.5.

3.3.4 Retransmission of cases

Based on regional reporting obligations and business arrangements in pharmacovigilance, an

ICSR may be re-transmitted several times between different senders and receivers. During this
re-transmission process, medical information ‘received’ on the case should not be omitted or
changed during the retransmission when no new information on the case is available to the re-
transmitting sender.

ICH ICSR Implementation Guide 10 November 2016

-33-
There are certain exceptions and the following data elements might be updated:
• Sender’s (case) Safety Report Unique Identifier (C.1.1);
• Date of Creation(C.1.2);
• Date Report Was First Received from Source (C.1.4);
• Date of Most Recent Information for This Report (C.1.5);
• Are Additional Documents Available? (C.1.6.1);
• Does This Case Fulfil the Local Criteria for an Expedited Report? (C.1.7);
• Information on Sender of Case Safety Report (C.3);
• Seriousness Criteria at Event Level (E.i.3.2);
• More Information Available (F.r.7);
• Assessment of Relatedness of Drug to Reaction(s)/ Event(s) (repeat as necessary)
(G.k.9.i.2.r);
• Sender's Diagnosis (repeat as necessary) (H.3.r);
• Sender's Comments (H.4); and
• English translation of the free text data elements in the ICSRs.

In addition to these data elements, it is also possible to update MedDRA coded data elements
with the most recent version of MedDRA.

There could be situations in which more than one ICSR shares the same ‘Worldwide Unique
Case Identification Number’ (C.1.8.1), or due to sequential updates to information in the same
case, more than one ICSR could share the same ‘Date of Most Recent Information’ (C.1.5).For
these situations, ‘Date of Creation’ (C.1.2) should be used to identify the most recent version of
the case.

3.3.5 Notes on Format of Data Elements

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 categorised 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;

ICH ICSR Implementation Guide 10 November 2016

-34-
 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.
In addition to the letters ‘i’ and ‘k’ indicating iterations of the event (E.i) or the drug (G.k), the
letter ‘r’ is used to indicate that the data element or the section is repeatable.

It is recognised that the numbering scheme for the data elements in this IG is
different than the one used in the E2B (R2).

3.3.6 General rules for Data Entry

• Date / Time Format

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’.

Please refer to Appendix II in this IG for more detail.

For E2B(R3), minimum level of date precision for each date data element is specified in
Section 3.4.

A single format (CCYYMMDDHHMMSS.UUUU[+|-ZZzz]) is used to represent

dates and times throughout this IG. This format allows for varying degrees of
precision to be exchanged for date and time information, from only the year, down
to the second.

The minimum level of precision for the date data elements is specified in Section
3.4, however, as much information as available (e.g. known) should be provided.

• All free text data elements (with the exception of the ‘Reaction/Event as Reported by the
Primary Source in Native Language’ (E.i.1.1a) and the ‘Case Summary and Reporter’s
Comments in Native Language’(H.5.r)) are to be provided in English for international

ICH ICSR Implementation Guide 10 November 2016

-35-
 transmission. However, the message control act wrapper supports language codes for
regional message exchanges. Please refer to regional implementation guides.
• Metric units should be used exclusively.
• For ICSR reporting, MedDRA is commonly used in the ICH regions. For additional advice
on MedDRA coding, refer to the latest edition of the ICH document ‘MedDRA Term
Selection: Points to Consider’.
• In certain instances, provisions have been made for transmission of free text items,
including a full text case summary narrative. Text data elements are intended to provide
additional information that cannot be provided in structured format using reference standard
terminology.
• Only one version of MedDRA can be used to code the relevant data elements within a
single ICSR. Therefore, the same MedDRA version should be identified each time a
MedDRA term is populated. However, multiple ICSRs are submitted in a single batch,
different ICSRs can refer to different MedDRA version.

For all data elements that reflect a MedDRA coded value, the same MedDRA
version should be used for all data elements in a single ICSR. However, when
multiple ICSRs are submitted in a single batch, different ICSRs can refer to
different MedDRA version.

It should be noted that:

• The data type for each element will be described as follows:

o A=Alpha: This data type is primarily used within the ICSR for certain data elements that
require controlled vocabulary, such as the ‘Reporter’s Country Code’(C.2.r.3) - 2A, to
accommodate the ISO3166 code. The string data elements that require the Alpha data
type can contain only upper and lower case alphabetic characters, e.g. ‘JP’. Numbers and
special characters, such as “.,^’ are not allowed;
o AN=AlphaNumeric: String data element that can contain alphabetic, numerical and
special characters. Example: ‘AB-19.990115‘”^’.Regarding all aspects of XML, the
W3C standards should be followed as published at http://www.w3.org/.For example,
when the XML special characters >, < and & occur in text, data elements they should
always be replaced by &gt; &lt; and &amp; respectively; or
o N=numeric: String data element that contains only the characters ‘0-9.E+-’ used to
represent an integer or floating point numbers, including scientific notation. Example:
‘1.23E-1’ or ‘34192’ or ‘32.12’.Commas are not permitted.
o Date: See Appendix II (A)
o Boolean: Boolean values are represented by:
 ‘false’ which can also equate to ‘no’;
 ‘true ’which can also equate to ‘yes’*;

ICH ICSR Implementation Guide 10 November 2016

-36-
  ‘nullflavor’ which can have different meanings in different scenarios. HL7 refers to
these as ‘null flavors’. (See below)
* For the purposes of this IG, there is one exception to this rule for the
‘Investigational Product Blinded’(G.k.2.5) where ‘true’= ‘blinded’.
• All mandatory data elements must always be part of the ICSR message, however optional
elements do not have to be transmitted. A blank optional element may not appear in the
XML code. A blank mandatory element needs to appear in the XML code for the message
to be valid.
o Some elements might need to be transmitted as part of a valid ICSR yet might need to be
empty of content for specific reasons. In HL7 messaging it is possible to transmit an
empty element and to code the element to explain the reason for the lack of data. This
allows for the creation of valid messages containing mandatory elements without
transmitting content. This reason for a blank element is referred to as the ‘flavor’ of the
null value.
o nullFlavors: ICH ICSR uses the following codes from the HL7 Messaging Standard to
categorise exceptions. For further information, please see the standard ISO / HL7 27953-
2. Not all nullFlavors are valid for all data types (e.g. PINF and NINF for non-numeric
data elements).

Code Name Definition

No information whatsoever can be inferred from this
No
NI exceptional value. This is the most general exceptional value.
Information
It is also the default exceptional value.
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
MSK Masked 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 A proper value is applicable, but not known.
Not No proper value is applicable in this context (e.g. last
NA
Applicable menstrual period for a male).
Asked But Information was sought but not found (e.g. patient was asked
ASKU
Unknown but didn't know)
This information has not been sought (e.g. patient was not
NASK Not Asked
asked)

ICH ICSR Implementation Guide 10 November 2016

-37-
 Code Name Definition
Negative
NINF Negative infinity of numbers.
Infinity
Positive
PINF Positive infinity of numbers.
Infinity

The following examples demonstrate how a nullFlavor can be used to code values in the ICH
ICSR. In these examples, the name of the data element appears after each coded value in a <!--
comment tag-->:
Example 1.‘Masked’ is expressed by nullFlavor =MSK.

<componenttypeCode="COMP">
<adverseEventAssessmentclassCode="INVSTG"moodCode="EVN">
<subject1typeCode="SBJ">
<primaryRoleclassCode="INVSBJ">
<player1classCode="PSN"determinerCode="INSTANCE">
<namenullFlavor="MSK"/>
<!-- D.1: Patient (name or initials) -->
<administrativeGenderCode code="D.5"codeSystem="1.0.5218"/>
<!-- D.5 Sex [1] Male [2]Female-->
<birthTime value="19200101"/>
<!-- D.2.1: Date of Birth -->
<deceasedTime value="20090101"/>

Example2.‘Unknown’ is expressed by nullFlavor=UNK.

<roleclassCode="PRS">
<code code="PRN"codeSystem="2.16.840.1.113883.5.111"/>
<associatedPersondeterminerCode="INSTANCE"classCode="PSN">
<namenullFlavor="UNK"/>
<!-- D.10.1: Parent Identification-->
<administrativeGenderCode code="D.10.6"codeSystem="1.0.5218"/>
<!-- D.10.6: Sex of Parent [1]Male [2]Female-->
<birthTime value="19730101"/>
<!-- D.10.2.1: Date of Birth of Parent -->
</associatedPerson>

3.3.7 Details of ICH E2B(R3) Data Elements

All of the E2B(R3) data elements and message specifications are described in tables in Section
3.4. The E2B(R3) data element table contains:

ICH ICSR Implementation Guide 10 November 2016

-38-
• the data element number;
o For the purpose of this IG, data elements for the Acknowledgement message will be
preceded by the letters ACK, for example:
 data element N.1.2 refers to the ‘Batch Number’ as detailed in Section 3.4; and
 ACK.M.1 refers to the ‘Acknowledgement Batch Number’ in the
Acknowledgement transaction.
• the data element name;
• a definition appears under ‘User Guidance’ to provide information on how to populate
correctly each E2B (R3) data element;
• ‘Conformance’ indicates if a value for the data element is mandatory / required or optional.
Some data elements are required for ‘technical’ reasons (e.g. to parse the message correctly)
and will generate an error when omitted. A list of required elements is provided in
Appendix I (G) the Technical Information.
• ‘Data Type’ and data element length－each data element will use a number to denote the
width of a data element followed by A for alpha, N for numeric, or AN for alphanumeric.
For data elements referencing a code set (e.g. not a free text data element), the organisation
that maintains the terminology should be consulted to obtain the most current specifications;
• an Object Identifier (‘OID’) －identifies if a specific code list or namespace applies to the
data element. The OIDs provided in this IG should be used in XML messages for the ICH
ICSR;
• ‘Value Allowed’ indicates possible values for the data element; and
• ‘Business Rule(s)’provide additional details on validation rules for some data elements.

The messaging specifications in this IG are the agreed, harmonised rules used by the ICH
parties. These are the validation conditions applied to ‘inbound’ ICH ICSR XML messages
(e.g. applied by ‘receivers’).Therefore, this IG should be used to verify the accuracy and
compliance of data entry when preparing an ‘outbound’ ICH ICSR XML message.

It is recognised that the information in ‘Value Allowed’ printed in this document for some code
lists may become outdated or incomplete. This information will be maintained outside this IG.
For a list of the most recent codes, please see the code lists in Appendix I (F).

The specifications in the ICH E2B(R3) data element in Section 3.4 are the
harmonised data validation rules in ICH. These data elements should be consulted
to verify the accuracy and compliance of data entry when preparing outbound ICH
ICSR XML messages.

For codes in ‘Value Allowed’, please see the most recent code lists in Appendix I
(F) ICH code lists.

ICH ICSR Implementation Guide 10 November 2016

-39-
3.4 ICH E2B(R3)Data Elements

N.1 ICH ICSR TRANSMISSION IDENTIFICATION (BATCH WRAPPER)

Unlike the information in ICSR sections C to F, the ‘wrapper’ information is intended for
routing purposes only (e.g. ‘from’ –>‘to’) and is not usually stored or archived. An assumption
is made that an Electronic Data Interchange (EDI) trading partnership agreement is established
to define the Message number, Sender ID, Receiver ID, and Message date conventions.

N.1 - ICH ICSR Transmission Identification (batch wrapper)

1…1

N.1 - ICH ICSR Transmission Identification (batch wrapper)

N.1.1 - Type of Messages in Batch

N.1.2 - Batch Number
N.1.3 - Batch Sender Identifier
N.1.4 - Batch Receiver Identifier
N.1.5 - Date of Message Creation

N.2.r - ICH ICSR Message Header (message wrapper)

N.2.r.1 - Message Identifier

1…n
N.2.r.2 - Message Sender Identifier
N.2.r.3 - Message Receiver Identifier
N.2.r.4 - Date of Message Creation

N.1.1 Type of Messages in Batch

User Guidance This data element contains information on the type of information being
transmitted. One ICH ICSR batch can contain one or more safety reports
(ICSRs).
Conformance Required
Data Type 2N
OID 2.16.840.1.113883.3.989.2.1.1.1
Value Allowed 1=ichicsr
Business Rule(s)
Note the ‘Value Allowed’ for this data element is case sensitive, e.g. only
lower case characters should be used for this data element.
Other codes may be used regionally.

One Batch can contain one or more ICSR messages. Each ICSR message contains
one ICSR.

ICH ICSR Implementation Guide 10 November 2016

-40-
N.1.2 Batch Number
User Guidance This data element, also called a ‘Batch Wrapper’, contains a unique
tracking number assigned by the sender to each outbound ICH ICSR batch
file. The batch number is unique only to the sender.
Conformance Required
Data Type 100AN
OID 2.16.840.1.113883.3.989.2.1.3.22
Value Allowed Free text
Business Rule(s)
The following notation will be used to represent N.1.2:
<id extension=”batch number" root="2.16.840.1.113883.3.989.2.1.3.22"/>

The root indicates the namespace of N.1.2, the actual batch number is
populated at id extension.

N.1.3 Batch Sender Identifier

User Guidance This data element identifies the origin of the ICSR reports (creator of ICH
ICSR batch file), e.g. company name or regulatory authority. The
identifier is unique to the receiver.
Conformance Required
Data Type 60AN
OID 2.16.840.1.113883.3.989.2.1.3.13
Value Allowed Free text
Business Rule(s)
The following notation will be used to represent N.1.3:
<id extension="sender identifier" root="2.16.840.1.113883.3.989.2.1.3.13"/>

The root indicates the namespace of N.1.3, the actual batch sender
identifier is populated at id extension.

The sender identifier should be agreed between trading partners.

ICH ICSR Implementation Guide 10 November 2016

-41-
N.1.4 Batch Receiver Identifier
User Guidance This data element identifies the intended destination of the ICSR batch
file. The identifier is unique to the sender.
Conformance Required
Data Type 60AN
OID 2.16.840.1.113883.3.989.2.1.3.14
Value Allowed Free text
Business Rule(s)
The following notation will be used to represent N.1.4:
<id extension="receiver identifier" root="2.16.840.1.113883.3.989.2.1.3.14"/>

The root indicates the namespace of N.1.4, the actual batch receiver
identifier is populated at id extension.

The receiver identifier should be agreed between trading partners.

N.1.5 Date of Batch Transmission

User Guidance This data element contains the date on which the ICH ICSR batch file was
transmitted.
Conformance Required
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
Business Rule(s)
The full precision of date and time must be recorded down to the second.
(i.e. ‘CCYYMMDDhhmmss[+/-ZZzz]’).
The date specified cannot refer to a future date.
The date should be local time at point of transmission of ICSR message.

N.2.r ICH ICSR MESSAGE HEADER (MESSAGE WRAPPER) (REPEAT AS

NECESSARY)

N.2.r.1 Message Identifier

User Guidance This data element contains the message identifier (also called the Message
Wrapper).It is a unique tracking identifier assigned to a specific ICH ICSR
message transmitted by the sender. One ICH ICSR message contains one
and only one ICSR.
Conformance Required
Data Type 100AN
OID 2.16.840.1.113883.3.989.2.1.3.1
Value Allowed Free text
Business Rule(s)
The value is the same as C.1.1.Therefore the notation would be:
<id extension="message identifier" root="2.16.840.1.113883.3.989.2.1.3.1"/>

ICH ICSR Implementation Guide 10 November 2016

-42-
N.2.r.2 Message Sender Identifier
User Guidance This data element identifies the sender of the ICSR reports (creator of ICH
ICSR message).
Conformance Required
Data Type 60AN
OID 2.16.840.1.113883.3.989.2.1.3.11
Value Allowed Free text
Business Rule(s)
The following notation will be used to represent N.2.r.2:
<id extension="message sender
identifier"root="2.16.840.1.113883.3.989.2.1.3.11"/>

The root indicates the namespace of N.2.r.2, the actual message sender
identifier is populated at id extension.

The sender identifier should be agreed between trading partners.

N.2.r.3 Message Receiver Identifier

User Guidance This data element identifies the intended recipient of the transmission of
the ICSR message.
Conformance Required
Data Type 60AN
OID 2.16.840.1.113883.3.989.2.1.3.12
Value Allowed Free text
Business Rule(s)
The following notation will be used to represent N.2.r.3:
<id extension="message receiver identifier"
root="2.16.840.1.113883.3.989.2.1.3.12"/>

The root indicates the namespace of N.2.r.3, the actual message receiver
identifier is populated at id extension. The receiver identifier should be
agreed between trading partners.

N.2.r.4 Date of Message Creation

User Guidance This data element contains the date on which the ICH ICSR message was
created in the sender’s database.
Conformance Required
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
Business Rule(s)
The value must be the same as C.1.2.
The full precision of date and time must be recorded down to the second
(i.e. CCYYMMDDhhmmss[+/-ZZzz]).

ICH ICSR Implementation Guide 10 November 2016

-43-
C.1 IDENTIFICATION OF THE CASE SAFETY REPORT

This section corresponds to the root of the case safety report. An ICH ICSR message file
contains one and only one ICSR; an ICH ICSR batch file contains one or more ICH ICSR
messages. Therefore, there must be one and only one ‘subject’ element within
‘controlActProcess’ in the ICSR message file.

C.1 - Identification of the case safety report

1…1

C.1 - Identification of the case safety report

C.1.1 - Sender’s (Case) Safety Report Unique Identifier

C.1.2 - Date of Creation
C.1.3 - Type of Report
C.1.4 - Date Report Was First Received from Source
C.1.5 - Date of Most Recent Information for this Report
C.1.6.1 - Are Additional Documents Available?
C.1.7 - Does this Case Fulfill the Local Criteria for an Expedited Report?
C.1.8.1 - Worldwide Unique Case Identification Number
C.1.8.2 - First Sender of this Case
C.1.9.1 - Other Case Identifiers in Previous Transmission
C.1.11.1 - Report Nullification/Amendment
C.1.11.2 - Reason for Nullification/Amendment

C.1.6.1.r - Documents Held by Sender

0…n (repeat as necessary)

C.1.6.1.r.1 - Documents Held by Sender

C.1.6.1.r.2 - Included Documents

0…n C.1.9.1.r - Other Case Identifiers (repeat as necessary)

C.1.9.1.r.1 - Other Case Identifiers in Previous Transmissions

C.1.9.1.r.2 - Case Identifier

C.1.10.r - Identification Number of the Report Which is Linked

0…n to this Report (repeat as necessary)
C.1.10.r - Identification Number of the Report Which Is Linked
to this Report

ICH ICSR Implementation Guide 10 November 2016

-44-
C.1.1 Sender’s (case) Safety Report Unique Identifier
User Guidance This data element contains an identifier for the ICSR that is unique. The
value should be a concatenation of3 segments separated by a dash/hyphen:
‘country code-company or regulator name-report number’. Country code
is the 2-letter ISO 3166 part 1 code (ISO 3166-1 alpha-2) corresponding to
the country of the primary source of the report (C.2.r.3). The company or
regulator name is an internationally unique abbreviation or code for the
sender’s organisation; the use of a ‘-‘ (dash/hyphen) should be avoided in
this segment. The report number is the organisation’s international case
number.

For example, a report transmitted from a company to a regulatory

authority concerning a case from France would populate C.1.1 with ‘FR-
companyname-12345’ where 12345 is that company’s unique case report
number.

When the same sender retransmits the same case (e.g. to transmit follow-
up information), C.1.1 usually remains constant. Exceptions are:
• In the case of an organisational change, (e.g. a merger between
companies or a name change), follow-up reports can be identified
in C.1.1 by the identifier of the newly named organisation.
• In the case of changes of country code for primary source for
regulatory purposes (C.2.r.3) or the country where the reaction
occurred (E.i.9), C.1.1 can be changed.
However, the ‘Worldwide Unique Case Identification Number’ (C.1.8.1)
used in any previous transmissions of the case should always remain the
same (See the user guidance for C.1.8).

Other retransmitters should replace this value with their own unique
identifier.
Conformance Required
Data Type 100AN
OID 2.16.840.1.113883.3.989.2.1.3.1
Value Allowed Free text (country code-company or regulator name-report number)
Business Rule(s)
A two character country code will be used in all instances for the country
component of the Unique Identifier. The country code EU exists in the
ISO 3166 country code list as an exceptional reservation code to support
any application that needs to represent the name European Union. In this
case, ‘EU’ will be accepted as the country code.

The format of C.1.1 ensures a unique report identifier for the sender of
particular ICSR.

The use of a ‘-’ (dash/hyphen) should be avoided in the ‘company or

regulator name’.

Both the ‘Sender's (case) Safety Report Unique Identifier’ (C.1.1) and the
‘Worldwide Unique Case Identification Number’ (C.1.8.1) data elements
are mapped to the repeatable XML attribute<id> in the

ICH ICSR Implementation Guide 10 November 2016

-45-
 ‘investigationEvent’ entity in the HL7 ICSR model (See Appendix I (D)
the Reference Instances).ICH uses two value－
‘2.16.840.1.113883.3.989.2.1.3.1’ and ‘2.16.840.1.113883.3.989.2.1.3.2’
－in the root portion of the investigationEvent.id to distinguish C.1.1 and
C.1.8.1.

The following notation will be used to represent C.1.1:

<id extension="country code-company name-report no"
root="2.16.840.1.113883.3.989.2.1.3.1"/>

The following notation will be used to represent C.1.8.1:

<id extension="country code-company name-report no"
root="2.16.840.1.113883.3.989.2.1.3.2"/>

C.1.2 Date of Creation

User Guidance This data element has the function of a timestamp and represents the
equivalent of a version number for the ICSR.
Every ICSR and every iteration (e.g. version) of an ICSR in a safety
message must have a different value for Date of Creation. The most
recent version of an ICSR will have the most recent date; previous
versions of an ICSR will have older dates.
Conformance Required
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
Business Rule(s)
Minimum precision required is date and time to the second.
The date specified cannot refer to a future date; the time zone may have to
be specified.
(i.e. ‘CCYYMMDDhhmmss[+/-ZZzz]’)

ICH ICSR Implementation Guide 10 November 2016

-46-
C.1.3 Type of Report
User Guidance This data element captures the type of report independently of its source; a
separate element for the designation of the source is covered in item C.4
and is not duplicated in this section.

For example, if a case in the literature arises from spontaneous

observations, ‘type of report’ should be Spontaneous report.

If a case in the literature arises from a study, ‘type of report’ should be

Report from study and the differentiation between types of studies (e.g.
clinical trials or others) should be given in Section C.5.4 (See the user
guidance for C.5.4).

If it is unclear from the literature report whether or not the case(s) cited
are spontaneous observations or whether they arise from a study, then this
item should be Other.

The Not available to sender option allows for the transmission of

information by a secondary sender (e.g. regulatory authority) where the
initial sender did not specify the type of report; it differs from Other,
which indicates that the sender knows the type of report but cannot fit it
into the categories provided.
Conformance Required
Data Type 1N
OID 2.16.840.1.113883.3.989.2.1.1.2
Value Allowed 1=Spontaneous report
2=Report from study
3=Other
4=Not available to sender (unknown)
Business Rule(s)

C.1.4 Date Report Was First Received from Source

User Guidance For organisations transmitting an initial case, this data element should be
the date when the information was received from the primary source and
fulfilling the 4 minimum criteria, as described in the Section 3.3.1.

When retransmitting information received from another regulatory agency

or another company or any other secondary source, C.1.4 should be the
date the retransmitter first received the information.
Conformance Required
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
Business Rule(s)
Minimum precision required is the day (i.e. ‘CCYYMMDD’).
The date specified cannot refer to a future date.

ICH ICSR Implementation Guide 10 November 2016

-47-
C.1.5 Date of Most Recent Information for This Report
User Guidance This data element captures the date each time follow-up information is
received by the sender from a primary source. However, if the case is
amended for any other reason (e.g. after internal review by the sender) this
date should not be changed, and the data element C.1.11.1 should be
populated with the value ‘amendment,’ indicating that the case was
amended by the sender. (See the user guidance for C.1.11.1)
Conformance Required
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
Business Rule(s)
Minimum precision required is the day (i.e. ‘CCYYMMDD’).
The date specified cannot refer to a future date.

The ‘Date of Most Recent Information for this Report’ should be changed each time
follow-up information is received by the sender.

The date originally reported in C.1.5 should not be changed in an amended or

nullified report if no new information on the case has been received.

C.1.6 Additional Available Documents Held by Sender

The documents received from the primary source (e.g. clinical records, hospital records, autopsy
reports, ECG strips, chest X-ray, photographs) should be listed individually. List all the
documents held by the sender, even if they are not actually forwarded to the receiver. Literature
reference documents, when available, are described in Section C.4, and are not duplicated in
C.1.6.

C.1.6.1 Are Additional Documents Available?

User Guidance When retransmitting information, the sender (retransmitter) indicates

‘true’ in this data element only if they have the documents available.
Conformance Required
Data Type Boolean
OID None
Value Allowed false
true
Business Rule(s)
For further information on how to attach documents to an ICSR, please
see Section 3.5.

ICH ICSR Implementation Guide 10 November 2016

-48-
C.1.6.1.r Documents Held by Sender (repeat as necessary)

C.1.6.1.r.1 Documents Held by Sender

User Guidance A description of the documents held by the sender relevant to this ICSR
(e.g. clinical records, hospital records, autopsy reports, ECG strips, chest
X-ray, or photographs) should be listed individually in this data element.
Conformance Optional, but required if C.1.6.1 is ‘true’.
Data Type 2000AN
OID None
Value Allowed Free text
Business Rule(s)

C.1.6.1.r.2 Included Documents

User Guidance This data element contains the actual content of C.1.6.1.r.1 if the sender
chooses to send the document.
Conformance Optional
Data Type N/A
OID None
Value Allowed Media type: e.g. Application/PDF, image/jpeg, application/DICOM,
text/plain
Representation: e.g.B64
Compression: e.g. DF
Business Rule(s)
For further information on how to attach documents to an ICSR, please
see Section 3.5.
Because a receiver’s system may have particular configurations on
handling attachments, ‘Value Allowed’ is defined by each region.

C.1.7 Does This Case Fulfil the Local Criteria for an Expedited Report?
User Guidance The definition of expedited is dependent upon the sender’s local
regulatory requirements. This data element should be used by the sender
to indicate whether the case fulfils the local expedited requirements.
When the countries of the sender and receiver differ, the receiver should
be aware that this information might not be applicable to the receiver’s
country’s regulatory requirements.
Conformance Required
Data Type Boolean
OID None
Value Allowed false
true
nullFlavor: NI*
Business Rule(s)
*’nullFlavor’ is only allowed when sender is retransmitting a case that
was first received ICH E2B (R2) format, where the equivalent data
element for C.1.7 was optionally not populated; in other cases, only ‘false’
or ‘true’ should be used.

ICH ICSR Implementation Guide 10 November 2016

-49-
C.1.8 Worldwide Unique Case Identification
Both C.1.8.1 and C.1.8.2 should always be populated and should never be changed in any
subsequent re-transmission.

When a sender has not previously received the ICSR in an electronic format (e.g. the
information was taken from a paper CIOMS, journal article, etc.) and thus creates the ‘initial’
electronic ICSR, the identifiers (content and format) in C.1.1 and C.1.8.1 are identical.

Retransmitters should use their own sender’s (case) safety report unique identifier in data
element C.1.1, but not change the values in data elements C.1.8.1 and C.1.8.2.

When a regulator is the initial sender, C.1.8.2 should be flagged as 1=Regulator.

When an entity other than a regulator is the initial sender, C.1.8.2 should be flagged as 2=Other.

C.1.8.1 Worldwide Unique Case Identification Number

User Guidance See Section C.1.8.

Because the data elements used to generate this identification number may
change over time (e.g. country code may become non-current), the
receiver should accept the value in this data element as is and not apply
particular business validation rules.
Conformance Required
Data Type 100AN
OID 2.16.840.1.113883.3.989.2.1.3.2
Value Allowed Free text (See C.1.1 user guidance for format)
Business Rule(s)
Both the ‘Sender's (case) Safety Report Unique Identifier’ (C.1.1) and the
‘Worldwide Unique Case Identification’ (C.1.8) data elements are mapped
to the repeatable XML attribute<id> in the ‘investigationEvent’ entity in
the HL7 ICSR model. (See the Reference Instance)ICH uses two values -
‘2.16.840.1.113883.3.989.2.1.3.1’ and ‘2.16.840.1.113883.3.989.2.1.3.2’
in the root portion of the investigationEvent.id to distinguish C.1.1 and
C.1.8.

The following notation will be used to represent C.1.1:

<id extension="country code-company name-report no" root="
2.16.840.1.113883.3.989.2.1.3.1 "/>

The following notation will be used to represent C.1.8:

<id extension="country code-company name-report no" root="

2.16.840.1.113883.3.989.2.1.3.2"/>

Although the attribute <id> can repeat in the message, but there must be a
single instance of the <id> attribute with the root value of
‘2.16.840.1.113883.3.989.2.1.3.2 ‘ for a particular case safety report.

ICH ICSR Implementation Guide 10 November 2016

-50-
 Retransmitters should use their own ‘Sender’s (case) Safety Report Unique
Identifier’ (C.1.1), but must not change C.1.8.1 and C.1.8.2.

C.1.8.2 First Sender of This Case

User Guidance This data element is used to identify the type of sender that created and
transmitted the original electronic ICSR.

When a regulator is the initial sender, C.1.8.2 should be flagged as

‘Regulator’.

When an entity other than a regulator is the initial sender, C.1.8.2 should
be flagged as ‘Other’.
Conformance Required
Data Type 1N
OID 2.16.840.1.113883.3.989.2.1.1.3
Value Allowed 1=Regulator
2=Other
Business Rule(s)

C.1.9 Other Case Identifiers

C.1.9.1 Other Case Identifiers in Previous Transmissions

User Guidance This data element should be completed only if the answer is ‘true’. In the
event that the ICSR either has been exchanged by the two parties in the
past using a different identifier or that it is exchanged simultaneously with
a different identifier, this other identifier should be listed in data element
C.1.9.1.r.2 and the organisations name should be captured in data element
C.1.9.1.r.1.
Conformance Required
Data Type Boolean
OID None
Value Allowed true
nullFlavor: NI
Business Rule(s)
False is not a value allowed for this data element. This mandatory data
element should either be ‘true’ or ‘nullFlavor’.

ICH ICSR Implementation Guide 10 November 2016

-51-
C.1.9.1.r Source(s) of the Case Identifier(s) (repeat as necessary)

C.1.9.1.r.1 Source(s) of the Case Identifier

User Guidance This repeatable data element should be used in conjunction with
C.1.9.1.r.2 to provide all sources (organisation’s name) of electronic
transmissions for this case. If the case has been received from another
sender, all other case identifiers included in C.1.9.1.r.1 (and C.1.9.1.r.2)
should be retransmitted. In addition, the case identifier assigned by the
previous sender in C.1.1 should be included here by the retransmitter.
Conformance Optional, but required if C.1.9.1=‘true’.
Data Type 100AN
OID 2.16.840.1.113883.3.989.2.1.3.3
Value Allowed Free text
Business Rule(s)
The following notation will be used to represent C.1.9.1.r.1:
<idassigningAuthorityName="C.1.9.1.r.1" extension="C.1.9.1.r.2"
root="2.16.840.1.113883.3.989.2.1.3.3"/>

The root indicates the namespace of C.1.9.1, the actual ‘Source of the
Case Identifier’ (C.1.9.1.r.1) and the ‘Case Identifier’ (C.1.9.1.r.2) are
populated at id and extension, respectively.

C.1.9.1.r.2 Case Identifier(s)

User Guidance This repeatable data element should be used in conjunction with
C.1.9.1.r.1 to provide all other case identifiers for this case used in ICH
ICSR electronic transmissions. If the case has been received from another
sender, all other case identifiers included in C.1.9.1.r.1 (and C.1.9.1.r.2)
should be retransmitted. In addition, the case identifier assigned by the
previous sender in C.1.1 should be included here by the retransmitter.
Conformance Optional, but required if C.1.9.1= ‘true’.
Data Type 100AN
OID 2.16.840.1.113883.3.989.2.1.3.3
Value Allowed Free text (See C.1.1 user guidance for format)
Business Rule(s)
The following notation will be used to represent C.1.9.1.r.2:
<idassigningAuthorityName="C.1.9.1.r.1" extension="C.1.9.1.r.2"
root="2.16.840.1.113883.3.989.2.1.3.3"/>

The root indicates the namespace of C.1.9.1, the actual source of the case
identifier (C.1.9.1.r.1) and case identifier (C.1.9.1.r.2) are populated at id
and extension, respectively.

ICH ICSR Implementation Guide 10 November 2016

-52-
C.1.10.r Identification Number of the Report Which Is Linked to This Report (repeat as
necessary)
User Guidance This data element captures an identifier of another report or case that
warrants being evaluated together with this ICSR. This includes, but is
not limited to, a mother/parent-child pair where both had events/reactions,
siblings with common exposure, several reports involving the same
patient, an ICSR previously sent via paper without a conformant E2B
Worldwide Unique Case Identification Number, or several similar reports
from same reporter (cluster). The reason for the linkage between ICSRs
should be provided in H.4.

For example, if a sender wishes to reference (link) an ICSR A to ICSR B,

then the sender populates the data element C.1.10.r in both reports:

ICSR C.1.8.1 C.1.10.r

A123 cc-MAHy-A123 cc-MAHy-B456
B456 cc-MAHy-B456 cc-MAHy-A123

This data element should be populated in both ICSRs when possible,

although there are cases in which one case may not have an E2B
Worldwide Unique Case Identification Number (e.g. legacy paper report
never transmitted in ICH E2B).
Conformance Optional
Data Type 100AN
OID None
Value Allowed Free text
Business Rule(s)

C.1.11 Report Nullification / Amendment

C.1.11.1 Report Nullification / Amendment

User Guidance This data element should be used to indicate that a previously transmitted
ICSR is either considered completely void (nullified) (for example when
the whole case was found to be erroneous), or amended (for example
when, after an internal review or according to an expert opinion, some
items have been corrected, such as adverse event/reaction terms,
seriousness, seriousness criteria or causality assessment). In case of
amendment it is important to use the same ‘Sender’s (case) Safety Report
Unique Identifier’ (C1.1) and ‘Worldwide Unique Case Identification’
(C.1.8) previously submitted (See exceptions in C.1.1).If it becomes
necessary to submit a report that has been previously nullified, a new
‘Sender’s (case) Safety Report Unique Identifier’ (C.1.1) and ‘Worldwide
Unique Identifier’ (C.1.8.1) should be assigned. The date originally
reported in C.1.5 should not be changed in an amended or nullified report
if no new information on the case has been received from a primary
source.
Conformance Optional
Data Type 1N

ICH ICSR Implementation Guide 10 November 2016

-53-
 OID 2.16.840.1.113883.3.989.2.1.1.5
Value Allowed 1=Nullification
2=Amendment
Business Rule(s)

C.1.11.2 Reason for Nullification / Amendment

User Guidance This item should be used to indicate the reason why a previously
transmitted ICSR is either considered completely void (nullified) (for
example when the whole case was found to be erroneous), or amended
(for example when, after an internal review or according to an expert
opinion, some items have been modified, such as adverse reaction/event
terms, seriousness, seriousness criteria or causality assessment). It is
important to use the same Worldwide Unique Identifier previously
submitted in C.1.8.1. The date originally reported in C.1.5 should not be
changed in an amended report.
Conformance Optional, but required when C.1.11.1 is populated.
Data Type 2000AN
OID None
Value Allowed Free text
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-54-
C.2.r PRIMARY SOURCE(S) OF INFORMATION (REPEAT AS NECESSARY)

The primary source of the information is the person who provides the facts about the ICSR. In
case of multiple sources, the ‘Primary Source for Regulatory Purposes’ (C.2.r.5) is the person
who first reported the facts to the sender. The primary source should be distinguished from
senders and retransmitters; the latter is captured in Section C.3.

C.2 - Primary Source(s) of Information

1…n
C.2.r - Primary Source(s) (repeat as necessary)
C.2.r.1.1 - Reporter’s Title
C.2.r.1.2 - Reporter’s Given Name
C.2.r.1.3 - Reporter’s Middle Name
C.2.r.1.4 - Reporter’s Family Name
C.2.r.2.1 - Reporter’s Organisation
C.2.r.2.2 - Reporter’s Department
C.2.r.2.3 - Reporter’s Street Address
C.2.r.2.4 - Reporter’s City
C.2.r.2.5 - Reporter’s State or Province
C.2.r.2.6 - Reporter’s Postcode
C.2.r.2.7 - Reporter’s Telephone
C.2.r.3 - Reporter’s Country Code
C.2.r.4 - Qualification
C.2.r.5 - Primary Source for Regulatory Purposes

Primary
Reporter’s Reporter’s
Reporter’s Source for
Address and Country Qualification
Name Regulatory
Telephone Code
Purposes
C.2.r.2.1
C.2.r.2.2
C.2.r.1.1
C.2.r.2.3
C.2.r.1.2
Data Element C.2.r.2.4 C.2.r.3 C.2.r.4 C.2.r.5
C.2.r.1.3
C.2.r.2.5
C.2.r.1.4
C.2.r.2.6
C.2.r.2.7
User Guidance The identification of the reporter (primary source) could be prohibited by
certain national or regional confidentiality requirements. The information
should be provided when it is in conformance with confidentiality
requirements.

However, at least one subsection for each Primary Source should be

completed to ensure that it is an identifiable reporter.

If only the name of the reporter is known and confidentiality requirements

prohibit transmission of the reporter’s full name or initials, the data elements
C.2.r.1.2, C.2.r.1.3, and/or C.2.r.1.4 can be masked and ‘populated’ with a
nullFlavor as appropriate, in compliance with confidentiality requirements or

ICH ICSR Implementation Guide 10 November 2016

-55-
 reporter request. Please see Section 3.3.6 for further guidance on the use of
nullFlavor to describe missing or non-transmitted information.
Business Rule(s)
Each ICSR shall have one primary reporter (primary source) identified in
conformance with regional confidentiality requirements.

Depending on the local legal requirements regarding confidentiality, it might

be necessary to mask some of the elements used to identify the reporter in the
transmitted message.

If the elements that are being used to identify the reporter are known to the
sender but cannot be transmitted due to data privacy requirements, then those
data elements should be left blank with nullFlavor = MSK.

Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

C.2.r.1 Reporter’s Name

C.2.r.1.1 Reporter’s Title

User Guidance This data element captures the reporter's title.

Conformance Optional
Data Type 50AN
OID None
Value Allowed Free text
nullFlavor: MSK, ASKU, NASK, UNK
Business Rule(s)
See the business rules for C.2.r.

C.2.r.1.2 Reporter’s Given Name

User Guidance This data element captures the reporter's given name.
Conformance Optional
Data Type 60AN
OID None
Value Allowed Free text
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
Seethe business rules for C.2.r.

ICH ICSR Implementation Guide 10 November 2016

-56-
C.2.r.1.3 Reporter’s Middle Name

User Guidance This data element captures the reporter's middle name.
Conformance Optional
Data Type 60AN
OID None
Value Allowed Free text
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
Seethe business rules for C.2.r.

ISO / HL7 27953-2 does not support the concept of ‘middle name’, thus
to transmit this in the message it is necessary to repeat the ‘given name’
tag. The first ‘given name’ tag captures reporter’s given name and the
second ‘given name’ tag captures reporter’s middle name. The order of
the tags indicate the order of the names.
<name>
<prefix>C.2.r.1.1</prefix>
<!--C.2.r.1.1: Reporter's Title #1 -->
<given>C.2.r.1.2</given>
<!--C.2.r.1.2: Reporter's Given Name #1 -->
<given>C.2.r.1.3</given>
<!--C.2.r.1.3: Reporter's Middle Name #1 -->
<family>C.2.r.1.4</family>
<!--C.2.r.1.4: Reporter's Family Name #1 -->
</name>

C.2.r.1.4 Reporter’s Family Name

User Guidance This data element captures the reporter's family name.
Conformance Optional
Data Type 60AN
OID None
Value Allowed Free text
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
See the business rules for C.2.r.

C.2.r.2 Reporter’s Address and Telephone

C.2.r.2.1 Reporter’s Organisation

User Guidance This data element captures the reporter's organisation’s name.
Conformance Optional
Data Type 60AN
OID None
Value Allowed Free text
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
See the business rules for C.2.r.

ICH ICSR Implementation Guide 10 November 2016

-57-
C.2.r.2.2 Reporter’s Department

User Guidance This data element captures the reporter's department name.
Conformance Optional
Data Type 60AN
OID None
Value Allowed Free text
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
See the business rules for C.2.r.

C.2.r.2.3 Reporter’s Street

User Guidance This data element captures the reporter's street name.
Conformance Optional
Data Type 100AN
OID None
Value Allowed Free text
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
See the business rules for C.2.r.

C.2.r.2.4 Reporter’s City

User Guidance This data element captures the reporter's city name.
Conformance Optional
Data Type 35AN
OID None
Value Allowed Free text
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
See the business rules for C.2.r.

C.2.r.2.5 Reporter’s State or Province

User Guidance This data element captures the reporter's State or Province.
Conformance Optional
Data Type 40AN
OID None
Value Allowed Free text
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
See the business rules for C.2.r.

ICH ICSR Implementation Guide 10 November 2016

-58-
C.2.r.2.6 Reporter’s Postcode

User Guidance This data element captures the reporter's postcode.

Conformance Optional
Data Type 15AN
OID None
Value Allowed Free text
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
See the business rules for C.2.r.

C.2.r.2.7 Reporter’s Telephone

User Guidance This data element captures the reporter's telephone number, including the
country code and any extension.
Numbers should be entered in a fashion that allows for international
dialling (e.g. +cc) and not include any domestic trunk prefix. For
example, in countries where the leading zero is used domestically, the
local 0xx-yyy-zzzz becomes international +cc-xx-yyy-zzzz.

Also, the phone number should not include domestic international dialling
prefixes (also known as country exit codes, such as 00 in Europe, 011 in
US, 010 in Japan).Begin with the International Telecommunications
Union plus sign (+) notation followed by the country code appropriate for
the location of the telephone number.

Additional visual separators for human readability are not required. If

used these characters should be limited to dashes ‘-‘ or dots ‘.’.
Conformance Optional
Data Type 33AN
OID None
Value Allowed Free text
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
See the business rules for C.2.r.

C.2.r.3 Reporter’s Country Code

User Guidance This data element captures the two letter ISO 3166 Part 1 code (ISO
3166-1 alpha-2) to represent the name of the reporter’s country.
Conformance Optional, but required if C.2.r.5 = 1.
Data Type 2A
OID 1.0.3166.1.2.2
Value Allowed ISO 3166-1 (alpha 2), EU
Business Rule(s)
A two character country code will be used in all instances.
The country code EU exists in the ISO 3166 country code list as an
exceptional reservation code to support any application that needs to
represent the name European Union.In this case, ‘EU’ will be accepted as
the country code.

ICH ICSR Implementation Guide 10 November 2016

-59-
C.2.r.4 Qualification
User Guidance This data element captures the reporter qualification.
Conformance Optional, but required if C.2.r.5 = 1.
Data Type 1N
OID 2.16.840.1.113883.3.989.2.1.1.6
Value Allowed 1=Physician
2=Pharmacist
3=Other health professional
4=Lawyer
5=Consumer or other non health professional
nullFlavor: UNK
Business Rule(s)
If the reporter’s qualification is unknown to the sender, this data element
should be left blank with nullFlavor = UNK.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

C.2.r.5 Primary Source for Regulatory Purposes

This data element identifies which primary source to use for regulatory
User Guidance purposes and in case of multiple sources, it identifies the source of the
World Wide Case Unique Identification number; this source should
identify where the case occurred.

The data element determines where the case will be reported as a

‘domestic’ case and where the case will be reported as a ‘foreign’ case.
Conformance Required for one and only one instance of this element.
Data Type 1N
OID None
Value Allowed 1=primary
Business Rule(s)
It is required that one Primary Source of Information (C.2) be flagged as
Primary source for regulatory purposes. Therefore this data element must
be set to ‘1’ once, and only once, for one C.2 block in each ICH ICSR
message.

Do not use this element to rank sources either sequentially,

chronologically, or hierarchically.

ICH ICSR Implementation Guide 10 November 2016

-60-
C.3 INFORMATION ON SENDER OF CASE SAFETY REPORT

C.3 - Information on Sender of Case Safety Report

1…1
C.3 - Information on Sender of Case Safety ReportSender

C.3.1 - Sender Type

C.3.2 - Sender’s Organisation
C.3.3.1 - Sender’s Department
C.3.3.2 - Sender’s Title
C.3.3.3 - Sender’s Given Name
C.3.3.4 - Sender’s Middle Name
C.3.3.5 - Sender’s Family Name
C.3.4.1 - Sender’s Street Address
C.3.4.2 - Sender’s City
C.3.4.3 - Sender’s State or Province
C.3.4.4 - Sender’s Postcode
C.3.4.5 - Sender’s Country Code
C.3.4.6 - Sender’s Telephone
C.3.4.7 - Sender’s Fax
C.3.4.8 - Sender’s E-mail Address

C.3.1 Sender Type

User Guidance This data element captures the type of sender organisation or individual.

In this context, ‘Pharmaceutical company’ includes biotechnology

companies, market authorisation holders and other manufacturers required
to submit ICSRs.
Conformance Required
Data Type 1N
OID 2.16.840.1.113883.3.989.2.1.1.7
Value Allowed 1=Pharmaceutical Company
2=Regulatory Authority
3=Health Professional
4=Regional Pharmacovigilance Centre
5=WHO collaborating centres for international drug monitoring
6=Other (e.g. distributor or other organisation)
7=Patient / Consumer
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-61-
C.3.2 Sender’s Organisation
User Guidance This data element captures the sender’s organisation name (e.g. company
name or regulatory authority name).
Conformance Required if the ‘Sender Type’ (C.3.1) is not coded as 7 (Patient /
Consumer).
Data Type 100AN
OID None
Value Allowed Free text
Business Rule(s)

C.3.3 Person Responsible for Sending the Report

Sender’s Sender’s Sender’s Sender’s Sender’s

Department Title Given Name Middle Name Family Name

Data Element C.3.3.1 C.3.3.2 C.3.3.3 C.3.3.4 C.3.3.5

User Guidance The name of person in the company or agency who is responsible for the
authorisation of report dissemination. This would usually be the same person
who signs the covering memo for paper submissions.

The identification of the person responsible for sending the ICSR could be
prohibited by certain national or international confidentiality requirements.
The information should be provided when it is in conformance with
confidentiality requirements.
Business Rule(s)
Depending on the local legal requirements regarding confidentiality, it might
be necessary to omit some of the elements used to identify the person
responsible for sending the report in the transmitted message.

C.3.3.1 Sender’s Department

User Guidance This data element captures the name of the sender’s department.
Conformance Optional
Data Type 60AN
OID None
Value Allowed Free text
Business Rule(s)
See the business rules for C.3.3.

C.3.3.2 Sender’s Title

User Guidance This data element captures the sender’s title.

Conformance Optional
Data Type 50AN
OID None
Value Allowed Free text
Business Rule(s)
See the business rules for C.3.3.

ICH ICSR Implementation Guide 10 November 2016

-62-
C.3.3.3 Sender’s Given Name

User Guidance This data element captures the sender’s given name.
Conformance Optional
Data Type 60AN
OID None
Value Allowed Free text
Business Rule(s)
See the business rules for C.3.3.

C.3.3.4 Sender’s Middle Name

User Guidance This data element captures the sender's middle name.
Conformance Optional
Data Type 60AN
OID None
Value Allowed Free text
Business Rule(s)
ISO / HL7 27953-2 does not support the concept of ‘middle name’, thus to
transmit this in the message it is necessary to repeat the ‘given name’ tag.
The first ‘given name’ tag captures sender’s given name and the second
‘given name’ tag captures sender’s middle name. The order of the tags
indicate the order of the names.
<name>
<prefix>C.3.3.2</prefix>
<!--C.3.3.2: Sender's Title #1 -->
<given>C.3.3.3</given>
<!--C.3.3.3: Sender's Given Name #1 -->
<given>C.3.3.4</given>
<!--C.3.3.4: Sender's Middle Name #1 -->
<family>C.3.3.5</family>
<!--C.3.3.5: Sender's Family Name #1 -->
</name>

See the business rules for C.3.3.

C.3.3.5 Sender’s Family Name

User Guidance This data element captures sender's family name.

Conformance Optional
Data Type 60AN
OID None
Value Allowed Free text
Business Rule(s)
See the business rules for C.3.3.

ICH ICSR Implementation Guide 10 November 2016

-63-
C.3.4 Sender’s Address, Fax, Telephone and E-mail Address
Sender’s Sender’s Sender’s Sender’s
Sender’s Sender’s Sender’s Sender’s
Street State or Country E-mail
City Postcode Telephone Fax
Address Province Code Address
Data
C.3.4.1 C.3.4.2 C.3.4.3 C.3.4.4 C.3.4.5 C.3.4.6 C.3.4.7 C.3.4.8
Element
User The sender's contact information should be provided in conformance with local or
Guidance international confidentiality requirements.
Business
Rule(s)
See the business rules for C.3.3.

C.3.4.1 Sender’s Street Address

User Guidance This data element captures the sender's street address.
Conformance Optional
Data Type 100AN
OID None
Value Allowed Free text
Business Rule(s)
See the business rules for C.3.3.

C.3.4.2 Sender’s City

User Guidance This data element captures the sender's city.

Conformance Optional
Data Type 35AN
OID None
Value Allowed Free text
Business Rule(s)
See the business rules for C.3.3.

C.3.4.3 Sender’s State or Province

User Guidance This data element captures the sender's state or province.
Conformance Optional
Data Type 40AN
OID None
Value Allowed Free text
Business Rule(s)
See the business rules for C.3.3.

ICH ICSR Implementation Guide 10 November 2016

-64-
C.3.4.4 Sender’s Postcode

User Guidance This data element captures the sender's postcode.

Conformance Optional
Data Type 15AN
OID None
Value Allowed Free text
Business Rule(s)
See the business rules for C.3.3.

C.3.4.5 Sender’s Country Code

User Guidance This data element captures the two letter ISO 3166 Part 1 code (ISO 3166-
1 alpha-2) to represent the name of the sender’s country.
Conformance Optional
Data Type 2A
OID 1.0.3166.1.2.2
Value Allowed ISO 3166-1 alpha-2
Business Rule(s)
See the business rules for C.3.3.

C.3.4.6 Sender’s Telephone

User Guidance This data element captures the sender’s telephone number, including the
country code and any extension.
Numbers should be entered in a fashion that allows for international
dialling (e.g. +cc) and not include any domestic trunk prefix. For
example, in countries where the leading zero is used domestically, the
local 0xx-yyy-zzzz becomes international +cc-xx-yyy-zzzz.

Also, the phone number should not include domestic international dialling
prefixes (also known as country exit codes, such as 00 in Europe, 011 in
US, 010 in Japan).Begin with the International Telecommunications
Union plus sign (+) notation followed by the country code appropriate for
the location of the telephone number.

Additional visual separators for human readability are not required. If

used these characters should be limited to dashes ‘-‘ or dots ‘.’.
Conformance Optional
Data Type 33AN
OID None
Value Allowed Free text
Business Rule(s)
See the business rules for C.3.3.

ICH ICSR Implementation Guide 10 November 2016

-65-
C.3.4.7 Sender’s Fax

User Guidance This data element captures the sender’s fax number, including the country
code and any extension.
Numbers should be entered in a fashion that allows for international
dialling (e.g. +cc) and not include any domestic trunk prefix. For
example, in countries where the leading zero is used domestically, the
local 0xx-yyy-zzzz becomes international +cc-xx-yyy-zzzz.

Also, the phone number should not include domestic international dialling
prefixes (also known as country exit codes, such as 00 in Europe, 011 in
US, 010 in Japan).Begin with the International Telecommunications
Union plus sign (+) notation followed by the country code appropriate for
the location of the telephone number.

Additional visual separators for human readability are not required. If

used these characters should be limited to dashes ‘-‘ or dots ‘.’.
Conformance Optional
Data Type 33AN
OID None
Value Allowed Free text
Business Rule(s)
See the business rules for C.3.3.

C.3.4.8 Sender’s E-mail Address

User Guidance This data element captures the sender’s email address.
Conformance Optional
Data Type 100AN
OID None
Value Allowed Free text
Business Rule(s)
See the business rules for C.3.3.

ICH ICSR Implementation Guide 10 November 2016

-66-
C.4.r Literature Reference(s) (repeat as necessary)

C.4 - Literature Reference(s)

0…n

C.4.r - Literature References (repeat as necessary)

C.4.r.1 - Literature Reference(s)

C.4.r.2 - Included Documents

C.4.r.1 Literature Reference(s)

User Guidance This data element should be used for literature article(s) that describe
individual case(s), but not for articles used for data analysis. Citations
should be provided in the style specified by the Vancouver Convention,
known as ‘Vancouver style’, which has been developed by the
International Committee of Medical Journal Editors. The conventional
styles, including styles for special situations, can be found in the following
reference:
International Committee of Medical Journal Editors. Uniform
requirements for manuscripts submitted to biomedical journals. N Engl J
Med 1997; 336:309-15.
Conformance Optional
Data Type 500AN
OID None
Value Allowed Free text
nullFlavor: ASKU, NASK
Business Rule(s)
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

C.4.r.2 Included Documents

User Guidance This data element contains the actual content referenced in C.4.r.1 when
the sender chooses to send a copy of the literature article.
Conformance Optional
Data Type N/A
OID None
Value Allowed Media type: e.g. Application/PDF, image/jpeg, application/DICOM,
text/plain
Representation: e.g.B64
Compression: e.g. DF
Business Rule(s)
For further information on how to attach documents to an ICSR, please
see Section 3.5.
Because a receiver’s system may have particular configurations on
handling attachments, ‘Value Allowed’ is defined by each region.

ICH ICSR Implementation Guide 10 November 2016

-67-
 The standard format to be used for literature citations, as well as formats for special
situations, can be found in the reference above, which is in the Vancouver style.

C.5 Study Identification

C.5 - Study Identification

0…1

C.5 - Study Identification

C.5.2 - Study Name

C.5.3 - Sponsor Study Number
C.5.4 - Study Type Where Reaction(s) / Event(s) Were Observed

0…n C.5.1.r - Study Registration (repeat as necessary)

C.5.1.r.1 - Study Registration Number

C.5.1.r.2 - Study Registration Country

C.5.1.r Study Registration (repeat as necessary)

C.5.1.r.1 Study Registration Number

User Guidance This repeatable data element should be populated with the study
registration number as assigned in a reporting region, e.g. EudraCT
number for reporting in the European Economic Area (EEA). Refer to
regional implementation guides for details.
Conformance Optional
Data Type 50AN
OID 2.16.840.1.113883.3.989.2.1.3.6
Value Allowed Free text
nullFlavor: ASKU, NASK
Business Rule(s)
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

The following notation will be used to represent C.5.1.r.1:

<id extension="study registration number"
root="2.16.840.1.113883.3.989.2.1.3.6"/>

The root indicates the namespace of C.5.1.r.1, the actual study registration
number is populated at id extension.

ICH ICSR Implementation Guide 10 November 2016

-68-
C.5.1.r.2 Study Registration Country

User Guidance This data element should be populated with the country that assigned the
Study Registration Number presented in C.5.1.r.1.Use the two letter ISO
3166 Part 1 code (ISO 3166-1 alpha-2) to represent the names of the
country.
Conformance Optional
Data Type 2A
OID 1.0.3166.1.2.2
Value Allowed ISO 3166-1 alpha-2, EU
nullFlavor: ASKU, NASK
Business Rule(s)
A two character country code will be used in all instances. The country
code EU exists in the ISO 3166 country code list as an exceptional
reservation code to support any application that needs to represent the
name European Union. In this case, ‘EU’ will be accepted as the country
code.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

C.5.2 Study Name

User Guidance This data element should be populated with the study name as registered
in the jurisdiction where the ICSR is reported.
Conformance Optional
Data Type 2000AN
OID None
Value Allowed Free text
nullFlavor: ASKU, NASK
Business Rule(s)
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

C.5.3 Sponsor Study Number

User Guidance This data element should be completed only if the sender is the study
sponsor or has been informed of the study number by the sponsor.
Conformance Optional
Data Type 50AN
OID 2.16.840.1.113883.3.989.2.1.3.5
Value Allowed Free text
nullFlavor: ASKU, NASK
Business Rule(s)
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.
The following notation will be used to represent C.5.3:
<id extension="sponsor study number"
root="2.16.840.1.113883.3.989.2.1.3.5"/>

The root indicates the namespace of C.5.3, the actual sponsor study
number is populated at id extension.

ICH ICSR Implementation Guide 10 November 2016

-69-
C.5.4 Study Type Where Reaction(s) / Event(s) Were Observed
User Guidance This information should be provided if the ‘Type of Report’(C.1.3) has
been populated with ‘Report from study’.
Conformance Optional, but required if C.1.3=2 (Report from study).
Data Type 1N
OID 2.16.840.1.113883.3.989.2.1.1.8
Value Allowed 1=Clinical trials
2=Individual patient use(e.g. ‘compassionate use’ or ‘named patient
basis’)
3=Other studies (e.g. pharmacoepidemiology, pharmacoeconomics,
intensive monitoring)
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-70-
D PATIENT CHARACTERISTICS

This section describes the singular subject who experienced one or several adverse
events/reactions. As many patient characteristics as available (e.g. known) should be provided.
However, at least one data element in Section D must be populated with a meaningful value or
masked to fulfil the criteria ‘one identifiable patient’ (See Section 3.3.1).

At least one of the data elements in Section D must be populated with a meaningful
value or masked to fulfil the criteria ‘one identifiable patient’.

In cases where a foetus or breast-feeding infant is exposed to one or several drugs through the
parent and experienced one or several adverse events/reactions, information on both the parent
and the child/foetus should be provided. Reports of these cases are referred to as parent-
child/foetus reports. The following general principles should be used for filing these reports.

• If there has been no event/reaction affecting the child/foetus, the parent-child/foetus report
does not apply; e.g. the data elements in Section D apply only to the parent (mother or
father) who experienced the adverse reaction/event.
Example: Mother suffers from pre-eclampsia and the child has no adverse reaction.
Only one ICSR should be completed for the mother, with the adverse event/reaction of
pre-eclampsia. No events/reactions are reported for the child, therefore a linked ICSR
for the child is not applicable.
• For those cases describing miscarriage, stillbirth or early spontaneous abortion, only a
mother report is applicable, e.g. the data elements in Section D apply to the mother.
However, if suspect drug(s) were taken by the father, this information should be indicated in
the data element G.k.10.r.
• If both the parent and the child/foetus sustain adverse event(s)/reaction(s), two separate
reports, e.g. one for the parent (mother or father) and one for the child/foetus, should be
provided and should be linked by using the data element C.1.10.r in each report.
Example: Mother suffers from pre-eclampsia and, at parturition, the baby had a low
birth weight and club foot. Two linked ICSRs should be submitted: The mother’s
report should have the adverse event/reaction of pre-eclampsia; the report for the baby
should have event/reaction terms for low birth weight and club foot. The term pre-
eclampsia would only apply to the mother’s case. The data element C.1.10.r should be
completed for both cases (e.g. the mother’s and baby’s).
• If only the child/foetus has an adverse event/reaction (other than early spontaneous
abortion/foetal demise) the information provided in this section applies only to the
child/foetus, and characteristics concerning the parent (mother or father) who was the
source of exposure to the suspect drug should be provided in Section D.10.
Example: A report of foetal distress, where the mother delivered via a Caesarean
section. There will be one ICSR for the baby, with the adverse event/reaction of foetal

ICH ICSR Implementation Guide 10 November 2016

-71-
 distress. The Caesarean section should not be considered an adverse event/reaction for
the mother. The mother’s characteristics, should be captured in Section D with the
Caesarean section as relevant medical history (D.10.7).
• If both parents are the suspect source of exposure to the suspect drug(s) then the case should
reflect the mother’s information in Section D.10 and the case narrative (Section H.1) should
describe the entire case, including the father’s information.

ICH ICSR Implementation Guide 10 November 2016

-72-
 D - Patient Characteristics
1…1
D - Patient Characteristics

D.1 - Patient (name or initials)

D.1.1.1 - Patient Medical Record Number(s) and the Source(s) of the Record Number (GP Medical Record Number)
D.1.1.2 - Patient Medical Record Number(s) and the Source(s) of the Record Number (Specialist Record Number)
D.1.1.3 - Patient Medical Record Number(s) and the Source(s) of the Record Number (Hospital Record Number)
D.1.1.4 - Patient Medical Record Number(s) and the Source(s) of the Record Number (Investigation Number)
D.3 - Body Weight (kg)
D.4 - Height (cm)
D.5 - Sex
D.6 - Last Menstrual Period Date
D.7.2 - Text for Relevant Medical History and Concurrent Conditions (not including reaction / event)
D.7.3 - Concomitant Therapies
D.9.1 - Date of Death
D.9.3 - Was Autopsy Done?

D.2 - Age Information

0…1 D.2.1 - Date of Birth

D.2.2a - Age at Time of Onset of Reaction / Event (number)
D.2.2b - Age at Time of Onset of Reaction / Event (unit)
D.2.2.1a - Gestation Period When Reaction / Event Was Observed in the Foetus (number)
D.2.2.1b - Gestation Period When Reaction / Event Was Observed in the Foetus (unit)
D.2.3 - Patient Age Group (as per reporter)

D.7.1.r - Structured Information on Relevant Medical History (repeat as necessary)

0…n D.7.1.r.1a - MedDRA Version for Medical History

D.7.1.r.1b - Medical history (disease / surgical procedure / etc.) (MedDRA code)
D.7.1.r.2 - Start Date
D.7.1.r.3 - Continuing
D.7.1.r.4 - End Date
D.7.1.r.5 - Comments
D.7.1.r.6 - Family History

D.8.r - Relevant Past Drug History (repeat as necessary)

0…n D.8.r.1 - Name of Drug as Reported

D.8.r.2a - MPID Version Date / Number
D.8.r.2b - Medicinal Product Identifier (MPID)
D.8.r.3a - PhPID Version Date / Number
D.8.r.3b - Pharmaceutical Product Identifier (PhPID)
D.8.r.4 - Start Date
D.8.r.5 - End Date
D.8.r.6a - MedDRA Version for Indication
D.8.r.6b - Indication (MedDRA code)
D.8.r.7a - MedDRA Version for Reaction
D.8.r.7b - Reaction (MedDRA code)

D.9.2.r - Reported Cause(s) of Death (repeat as necessary)

0…n D.9.2.r.1a - MedDRA Version for Reported Cause(s) of Death

D.9.2.r.1b - Reported Cause(s) of Death (MedDRA code)
D.9.2.r.2 - Reported Cause(s) of Death (free text)

Continued on Next Page

ICH ICSR Implementation Guide 10 November 2016

-73-
 D - Patient Characteristics

Continued from Previous Page

D.9.4.r - Autopsy-determined Cause(s) of Death (repeat as necessary)

0…n D.9.4.r.1a - MedDRA Version for Autopsy-determined Cause(s) of Death
D.9.4.r.1b - Autopsy-determined Cause(s) of Death (MedDRA code)
D.9.4.r.2 - Autopsy-determined Cause(s) of Death (free text)

D.10 - For a Parent-Child / Foetus Report, Information Concerning the Parent

0…1 D.10.1 - Parent Identification

D.10.2.1 - Date of Birth of Parent
D.10.2.2 - Age of Parent
D.10.2.2a - Age of Parent (number)
D.10.2.2b - Age of Parent (unit)
D.10.3 - Last Menstrual Period Date of Parent
D.10.4 - Body Weight (kg) of Parent
D.10.5 - Height (cm) of Parent
D.10.6 - Sex of Parent

D.10.7 - Relevant Medical History and Concurrent Conditions of Parent

0…1
D.10.7.2 - Text for Relevant Medical History and Concurrent Conditions of Parent

D.10.7.1.r - Structured Information of Parent (repeat as necessary)

0…n D.10.7.1.r.1a - MedDRA Version for Medical History

D.10.7.1.r.1b - Medical History (disease / surgical procedure/ etc.) (MedDRA code)
D.10.7.1.r.2 - Start Date
D.10.7.1.r.3 - Continuing
D.10.7.1.r.4 - End Date
D.10.7.1.r.5 - Comments

D.10.8.r - Relevant Past Drug History of Parent (repeat as necessary)

D.10.8.r.1 - Name of Drug as Reported

0…n
D.10.8.r.2a - MPID Version Date / Number
D.10.8.r.2b - Medicinal Product Identifier (MPID)
D.10.8.r.3a - PhPID Version Date / Number
D.10.8.r.3b - Pharmaceutical Product Identifier (PhPID)
D.10.8.r.4 - Start Date
D.10.8.r.5 - End Date
D.10.8.r.6a - MedDRA Version for Indication
D.10.8.r.6b - Indication (MedDRA code)
D.10.8.r.7a - MedDRA Version for Reaction
D.10.8.r.7b - Reactions (MedDRA code)

ICH ICSR Implementation Guide 10 November 2016

-74-
D.1 Patient (name or initials)
User Guidance It is important that this data element is populated. The identification of
the patient might be prohibited by certain national confidentiality laws or
directives. The information should be provided when it is in conformance
with the confidentiality requirements.
Conformance Required
Data Type 60AN
OID None
Value Allowed Free text
nullFlavor: MSK, ASKU, NASK, UNK
Business Rule(s)
If the initials are known to the sender but cannot be transmitted due to data
privacy requirements, this data element should be left blank with
nullFlavor = MSK.

Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

D.1.1 Patient Medical Record Number(s) and Source(s) of the Record Number (if
allowable)
Record numbers can include the health professional record(s) number(s), hospital record(s)
number(s), or patient/subject identification number in a study. The most appropriate data
element should be used in order to indicate the source of the number and facilitate record
retrieval when possible and desirable.

The patient identification in a clinical trial can be transmitted below in the ‘Patient Medical
Record Number(s) and Source(s) of the Record Number (Investigation
number)’(D.1.1.4).Multiple elements should be extracted from the source database, like Centre
ID, Patient ID and a random (check) number, and concatenated in this element to assure a
unique patient identification.

D.1.1.1 Patient Medical Record Number(s) and Source(s) of the Record Number (GP
Medical Record Number)

User Guidance See Section D.1.1.

Conformance Optional
Data Type 20AN
OID 2.16.840.1.113883.3.989.2.1.1.4and 2.16.840.1.113883.3.989.2.1.3.7
Value Allowed Free text
nullFlavor: MSK
Business Rule(s)
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

The following notation will be used to represent D.1.1.1:

<id extension="medical record number"
root="2.16.840.1.113883.3.989.2.1.3.7"/>
<code code="gpmrn"codeSystem="2.16.840.1.113883.3.989.2.1.1.4"/>

ICH ICSR Implementation Guide 10 November 2016

-75-
 The root indicates the namespace of D.1.1.1, the actual medical record
number is populated at id extension. The code of ‘gpmn’ is populated to
distinguish from D.1.1.2 to D.1.1.4.

D.1.1.2 Patient Medical Record Number(s) and Source(s) of the Record Number
(Specialist Record Number)

User Guidance See Section D.1.1.

Conformance Optional
Data Type 20AN
OID 2.16.840.1.113883.3.989.2.1.1.4and 2.16.840.1.113883.3.989.2.1.3.8
Value Allowed Free text
nullFlavor: MSK
Business Rule(s)
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

The following notation will be used to represent D.1.1.2:

<id extension="medical record
number"root="2.16.840.1.113883.3.989.2.1.3.8"/>
<code code="specialistMrn"codeSystem="2.16.840.1.113883.3.989.2.1.1.4"/>

The root indicates the namespace of D.1.1.2, the actual medical record
number is populated at id extension. The code of ‘specialistMrn’ is
populated to distinguish from D.1.1.1, D.1.1.3 and D.1.1.4.

D.1.1.3 Patient Medical Record Number(s) and Source(s) of the Record Number (Hospital
Record Number)

User Guidance See Section D.1.1.

Conformance Optional
Data Type 20AN
OID 2.16.840.1.113883.3.989.2.1.1.4 and 2.16.840.1.113883.3.989.2.1.3.9
Value Allowed Free text
nullFlavor: MSK
Business Rule(s)
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

The following notation will be used to represent D.1.1.3:

<id extension=" medical record number "
root="2.16.840.1.113883.3.989.2.1.3.9"/>
<code code="hospitalMrn"codeSystem="2.16.840.1.113883.3.989.2.1.1.4"/>

The root indicates the namespace of D.1.1.3, the actual medical record
number is populated at id extension. The code of ‘hospitalMrn’ is
populated to distinguish from D.1.1.1, D.1.1.2 and D.1.1.4.

ICH ICSR Implementation Guide 10 November 2016

-76-
D.1.1.4 Patient Medical Record Number(s) and Source(s) of the Record Number
(Investigation Number)

User Guidance See Section D.1.1.

Conformance Optional
Data Type 20AN
OID 2.16.840.1.113883.3.989.2.1.1.4 and 2.16.840.1.113883.3.989.2.1.3.10
Value Allowed Free text
nullFlavor: MSK
Business Rule(s)
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

The following notation will be used to represent D.1.1.4:

<id extension=" medical record number "
root="2.16.840.1.113883.3.989.2.1.3.10"/>
<code code="investigation"codeSystem="2.16.840.1.113883.3.989.2.1.1.4"/>

The root indicates the namespace of D.1.1.4, the actual medical record
number is populated at id extension. The code of ‘investigation’ is
populated to distinguish from D.1.1.1 to D.1.1.3.

D.2 Age Information

Only one of the elements describing age should be used. The choice should be based upon the
most precise information available and in conformance with the regional confidentiality
requirements.

D.2.1 Date of Birth

User Guidance This data element captures the full precision date (e.g. day, month, year)
for the date of birth of the patient. If the full date of birth is not known, an
approximate age can be captured in Section D.2.2.Alternatively, the
‘Patient Age Group (as per reporter)’ (D.2.3) can be used to indicate the
age of the patient.
Conformance Optional
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
nullFlavor: MSK
Business Rule(s)
Minimum precision required is the day (i.e. ‘CCYYMMDD’).
The date specified cannot refer to a future date.
If the date of birth is known to the sender but cannot be transmitted due to
data privacy requirements, this data element should be left blank with
nullFlavor = MSK.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

ICH ICSR Implementation Guide 10 November 2016

-77-
D.2.2 Age at Time of Onset of Reaction / Event

If several reactions/events are in the report, the age at the time of the first reaction/event should
be used. For foetal reaction(s)/event(s), the Gestation Period When Reaction/ Event Was
Observed in the Foetus (D.2.2.1) should be used.

When providing the age in decades, please note that, for example, the 7th decade refers to a
person in his/her 60’s.

D.2.2a Age at Time of Onset of Reaction / Event (number)

User Guidance See Section D.2.2.

Conformance Optional, but required if D.2.2b is populated.
Data Type 5N
OID None
Value Allowed Numeric
Business Rule(s)

D.2.2bAge at Time of Onset of Reaction / Event (unit)

User Guidance See Section D.2.2.

Conformance Optional, but required if D.2.2a is populated.
Data Type 50AN
OID 2.16.840.1.113883.3.989.2.1.1.26
Value Allowed UCUM codes for Year, Month, Week, Day, and Hour: {Decade}
Business Rule(s)

The gestation period at the time of exposure is captured in Section G.k.6.

D.2.2.1a Gestation Period When Reaction / Event Was Observed in the Foetus (number)

User Guidance This data element captures the value (quantity) for the gestation period
when the reaction/event was observed in the foetus.
Conformance Optional, but required if D.2.2.1b is populated.
Data Type 3N
OID None
Value Allowed Numeric
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-78-
D.2.2.1b Gestation Period When Reaction/Event Was Observed in the Foetus (unit)

User Guidance This data element captures the unit for the value of the gestation period
when the reaction/event was observed in the foetus.
Conformance Optional, but required if D.2.2.1a is populated.
Data Type 50AN
OID 2.16.840.1.113883.3.989.2.1.1.26
Value Allowed UCUM codes for Month, Week, and Day:{Trimester}
Business Rule(s)

D.2.3 Patient Age Group (as per reporter)

User Guidance The terms in Value Allowed for this data element are not defined in this
document and are intended to reflect the term used by the reporter (i.e. as
they were reported by the primary source).This section should be
completed only when the age is not provided with any more precision (e.g.
Sections D.2.1 or D.2.2 is blank).
Conformance Optional
Data Type 1N
OID 2.16.840.1.113883.3.989.2.1.1.9
Value Allowed 0=Foetus
1=Neonate (Preterm and Term newborns)
2=Infant
3=Child
4=Adolescent
5=Adult
6=Elderly
Business Rule(s)

D.3 Body Weight (kg)

User Guidance This data element captures the reported body weight of the patient in
kilograms at the time of the event/reaction.
Conformance Optional
Data Type 6N
OID None
Value Allowed Numeric
Business Rule(s)
Fractions or decimals are allowed using a period (dot).No commas are
allowed in this numeric data element.

ICH ICSR Implementation Guide 10 November 2016

-79-
D.4 Height (cm)
User Guidance This data element captures the reported height of the patient in centimetres
at the time of the event/reaction.
Conformance Optional
Data Type 3N
OID None
Value Allowed Numeric
Business Rule(s)
Provide rounded number. No fractions, decimals, and commas are
allowed in this numeric data element.

D.5 Sex
User Guidance This data element captures the sex of the patient.
Conformance Optional
Data Type 1N
OID 1.0.5218
Value Allowed 1=Male
2=Female
nullFlavor: MSK, UNK, ASKU, NASK
Business Rule(s)
If the sex is known to the sender but cannot be transmitted due to data
privacy requirements, then leave the data element blank and use the
nullFlavor element with ‘MSK’ as masked.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

D.6 Last Menstrual Period Date

User Guidance This data element captures the date of the last menstrual period of the
patient when it is relevant. Imprecise dates can be included (e.g. month
and year, or year only).Other information on menopause or conditions
related to menopause should be captured in the data element D.7.1.r.

If this report is for a child/foetus, then the mother’s last menstrual period
is captured in the data element D.10.3.
Conformance Optional
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
nullFlavor: MSK
Business Rule(s)
Minimum precision required is the year (i.e. ‘CCYY’).
The date specified cannot refer to a future date.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

ICH ICSR Implementation Guide 10 November 2016

-80-
D.7 Relevant Medical History and Concurrent Conditions (not including reaction / event)

D.7.1.r Structured Information on Relevant Medical History (repeat as necessary)

Medical judgment should be exercised in completing this section. Only information pertinent to
understanding the case is desired (such as diseases, conditions such as pregnancy, surgical
procedures, psychological trauma, risk factors, etc.). In case of prematurity, the birth weight
when known should be recorded in the data element ‘Comments’ (D.7.1.r.5). If precise dates
are not known and a text description is pertinent to understanding the medical history, or if
concise additional information is helpful in showing the relevance of the past medical history,
such information can be included in the ‘Comments’ (D.7.1.r.5). In order to identify relevant
medical information of the family (e.g. hereditary diseases), the data element ‘Family History’
(D.7.1.r.6) should be set to ‘true’ (Yes) for the appropriate medical history of the patient.

If there is no relevant medical history and no concurrent conditions for inclusion in D.7.1, then
D.7.2 is required. If the reason is that the relevant medical history is not documented at the time
of the report then the value for D.7.2 is ‘Unknown’. This should not be confused with ‘None’.
In the first case the NullFlavor is used with the value ‘UNK’ and in the second case the text
‘None’ will be transmitted.

The designation of ‘r’ in this section indicates that each item is repeatable and that it
corresponds to the same ‘r’ in all subsections. A separate block (r) should be used for each
relevant medical history term. For example, if two conditions are reported, the first condition
would be described in items D.7.1.1.1 through D.7.1.1.6, and the other condition would be
described in items D.7.1.2.1 through D.7.1.2.6.

D.7.1.r.1a MedDRA Version for Medical History

User Guidance This data element provides the MedDRA version for D.7.1.r.1b.
Conformance Optional, but required if D.7.1.r.1b is populated.
Data Type 4AN
OID None
Value Allowed Numeric and ‘.‘(dot)
Business Rule(s)
Only 1 MedDRA version is allowed per ICSR.
For MedDRA version 15.1 value allowed is ‘15.1’.

D.7.1.r.1b Medical History (disease / surgical procedure / etc.) (MedDRA code)

User Guidance See Section D.7.1.r.

Conformance Optional, but required if D.7.1.r.1a is populated.
Data Type 8N
OID 2.16.840.1.113883.6.163
Value Allowed Numeric
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-81-
D.7.1.r.2 Start Date

User Guidance This data element captures the start date of the patient’s medical
condition. Imprecise dates can be used for both start and end dates,
although the highest precision is desirable.
Conformance Optional
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
Minimum precision required is the year (i.e. ‘CCYY’).
The date specified cannot refer to a future date.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

D.7.1.r.3 Continuing

User Guidance This data element indicates if the ‘medical condition’ in D.7.1.r.1b is
known to be still present at the time of this report.
Conformance Optional
Data Type Boolean
OID None
Value Allowed false
true
nullFlavor: MSK, ASKU, NASK, UNK
Business Rule(s)
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

D.7.1.r.4 End Date

User Guidance This data element captures the end date of the patient’s medical condition.
Imprecise dates can be used for both start and end dates, although the
highest precision is desirable.
Conformance Optional
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
Minimum precision required is the year (i.e. ‘CCYY’).
The date specified cannot refer to a future date.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

ICH ICSR Implementation Guide 10 November 2016

-82-
D.7.1.r.5 Comments

User Guidance This data element provides additional relevant information about the
‘medical condition’ in D.7.1.r.1b that could not be captured otherwise in a
structured data element. For example, in case of prematurity, the birth
weight should be recorded here; or in the absence of imprecise dates, a
text description that would aid in understanding the medical history (e.g.
‘since childhood’) can also be provided here.
Conformance Optional
Data Type 2000AN
OID None
Value Allowed Free text
Business Rule(s)

D.7.1.r.6 Family History

User Guidance This data element captures is set to ‘true’ when the medical information
provided in the ‘Structured Information on Relevant Medical
History’(D.7.1.r) is reported also to be present in another family member
(e.g. hereditary diseases). However, this data element is not used when
the same medical concept is already provided in the ‘Relevant Medical
History and Concurrent Conditions of Parent’(D.10.7). When this data
element is set to ‘true’, detailed information should be provided in the
narrative Section H.1.
Conformance Optional
Data Type Boolean
OID None
Value Allowed True
Business Rule(s)
When Parent Medical history already is provided in D.10.7, do not set this
data element to ‘true’ (Yes) for similar medical concepts also coded for
the patient.

D.7.2 Text for Relevant Medical History and Concurrent Conditions (not including
reaction / event)

User Guidance This data element captures information about any other medical history
that could not be coded in D.7.1.r.

Also, the term ‘None’ should be used here when there is no relevant
medical history and no concurrent conditions reported.

If relevant medical history is not documented at the time of the report, this
data element is set to unknown (i.e. nullFlavor=UNK) and should not be
confused with ‘None’.
Conformance Optional, but required if Section D.7.1 is null.
Data Type 10000AN
OID None
Value Allowed Free text

ICH ICSR Implementation Guide 10 November 2016

-83-
 nullFlavor: MSK, ASKU, NASK, UNK
Business Rule(s)
If the relevant medical history is unknown to the sender (e.g. not
reported), this data element should be left blank with nullFlavor = UNK.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

D.7. 3 Concomitant Therapies

User Guidance This data element indicates at the time of the reaction there were
concomitant therapies such as radiotherapy, drug class, dietary
supplements or other products not otherwise describable in Section G.
When this data element is set to ‘true’, details should be provided in the
narrative Section H.1.
Conformance Optional
Data Type Boolean
OID None
Value Allowed True
Business Rule(s)

In case of concomitant medication(s) the structured information on the medicinal

product(s) should be provided in Section G. In case of other administered
therapies that cannot be structured in Section G, then the data element D.7.3 is set
to true and details are provided in the narrative Section H.1.

D.8.r Relevant Past Drug History (repeat as necessary)

This section concerns relevant drugs previously administered and which have been stopped
before the Adverse Event onset. It does not concern drugs taken concomitantly or drugs which
might have potentially been involved in the current reaction(s)/event(s). Medical judgment
should be exercised in completing this section. Medications that have been stopped might be
considered suspect based on the elimination half-life of the drug and the known
pharmacodynamic effects of the drug in a particular patient (for example, a patient with known
renal or liver impairment).Information concerning concomitant and other suspect drugs should
be included in Section G. The information provided here can also include previous experience
with similar drugs.

Based on the medicinal product name as reported by the primary source, the most specific ISO
IDMP identifier - the Medicinal Product Identifier (MPID) or the Pharmaceutical Product
Identifier (PhPID) - should be provided. If a MPID or a PhPID for the reported medicinal
product is not available, these data elements should be left blank.

ICH ICSR Implementation Guide 10 November 2016

-84-
A MedDRA LLT numeric code should be used for the ‘Indication’ (D.8.r.6b) and the ‘Reaction’
(D.8.r.7b).In the event of previous exposure to drug(s) or vaccine(s) without reaction, the
MedDRA code ‘No adverse effect’ should be used in the Reaction column. Imprecise dates can
be used for both start and end dates.

The designation of ‘r’ in this section indicates that each item is repeatable and that it
corresponds to the same ‘r’ in all subsections. A separate block (r) should be used for each
relevant drug term. For example, if two drugs are reported, the first drug would be described in
items D.8.1.1 through D.8.1.7 and the other drug would be described in items D.8.2.1 through
D.8.2.7.

Overall, a conservative approach should be taken and if there is any doubt, the product should
be considered a suspect drug. If there are critical or controversial issues to be discussed in
regard to this judgment they can be briefly mentioned in a narrative in Section H.

As a general principle all drugs that were completed / discontinued before the start
of the treatment with the suspect(ed) drug(s) should be included in the ‘Relevant
Past Drug History’ section (D.8). Any drug(s) that are not suspected of causing the
event or reaction and that are administered to the patient at the time of the reaction
should be listed as concomitant medication in Section G.

A history of allergy to a specific drug is preferably reported in Section D.8

‘Relevant Past Drug History’, using the suspect drug name and MedDRA terms in
the indication and reaction data elements. These data elements are often searchable
in most databases and thus this is the preferred option.

When a non-specific allergy is reported (e.g. ‘sulfa’ allergy is reported, but

unknown if to a sulphonamide antibiotic or to a sulfa-containing diuretic), this
information could be reported in Section D.7.1 ‘Structured information on relevant
medical history’ by using the LLT ‘Drug hypersensitivity’ (or a more descriptive
LLT) under ‘Disease / surgical procedure / etc.’, and the name of the drug under
‘comments’.

ICH ICSR Implementation Guide 10 November 2016

-85-
D.8.r.1 Name of Drug as Reported

User Guidance This data element captures the name of the medicinal product as used by
the reporter. It is recognized that a single product can have different
proprietary names in different countries, even when it is produced by a
single manufacturer. Trade name, generic name or class of drug can be
used.
Conformance
Optional, but required by the schema if any data element in section D.8.r
is used.
Data Type 250AN
OID None
Value Allowed Free text
nullFlavor: UNK, NA
Business Rule(s)
Nullflavor=NA should be used when there is no previous exposure to a
drug or vaccine.
Null flavor = UNK is allowed when there is previous drug history but the
name of the drug or vaccine is not known.

D.8.r.2a MPID Version Date/Number

User Guidance This data element provides the version date for D.8.r.2b.
Conformance Optional
Data Type As per ISO IDMP.
OID None
Value Allowed As per ISO IDMP.
Business Rule(s)

D.8.r.2b Medicinal Product Identifier (MPID)

User Guidance This data element captures MPID. If an MPID for the reported medicinal
product is not available, this data element should be left blank.
Conformance Optional
Data Type As per ISO IDMP.
OID As per ISO IDMP.
Value Allowed As per ISO IDMP.
Business Rule(s)
Any given drug entry may have either MPID or PhPID, but NOT both.

D.8.r.3a PhPID Version Date/Number

User Guidance This data element provides the version date for D.8.r.3b.
Conformance Optional
Data Type As per ISO IDMP.
OID None
Value Allowed As per ISO IDMP.
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-86-
D.8.r.3b Pharmaceutical Product Identifier (PhPID)

User Guidance This data element captures the PhPID. If a PhPID for the reported
medicinal product is not available, this data elements should be left blank.
Conformance Optional
Not allowed if D.8.r.2 is populated.
Data Type As per ISO IDMP.
OID As per ISO IDMP.
Value Allowed As per ISO IDMP.
Business Rule(s)
Any given drug entry may have either MPID or PhPID, but NOT both.

D.8.r.4 Start Date

User Guidance This data element captures the start date of the medicinal product.
Imprecise dates can be used for both start and end dates.
Conformance Optional
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
Minimum precision required is the year (i.e. ‘CCYY’).
The date specified cannot refer to a future date.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

D.8.r.5 End Date

User Guidance This data element captures the start date of the medicinal product.
Imprecise dates can be used for both start and end dates.
Conformance Optional
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
Minimum precision required is the year (i.e. ‘CCYY’).
The date specified cannot refer to a future date.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

ICH ICSR Implementation Guide 10 November 2016

-87-
D.8.r.6a MedDRA Version for Indication

User Guidance This data element provides the MedDRA version for D.8.r.6b.
Conformance Optional, but required if D.8.r.6b is populated.
Data Type 4AN
OID None
Value Allowed Numeric and ‘.‘(dot)
Business Rule(s)
Only 1 MedDRA version is allowed per ICSR.
For MedDRA version 15.1 value allowed is ‘15.1’.

D.8.r.6b Indication (MedDRA code)

User Guidance This data element captures the MedDRA LLT code for the indication of
the medicinal product.
Conformance Optional, but required if D.8.r.6a is populated.
Data Type 8N
OID 2.16.840.1.113883.6.163
Value Allowed Numeric
Business Rule(s)

D.8.r.7a MedDRA Version for Reaction

User Guidance This data element provides the MedDRA version for D.8.r.7b.
Conformance Optional, but required if D.8.r.7b is populated.
Data Type 4AN
OID None
Value Allowed Numeric and ‘.‘(dot)
Business Rule(s)
Only 1 MedDRA version is allowed per ICSR.
For MedDRA version 15.1 value allowed is ‘15.1’.

D.8.r.7bReaction (MedDRA code)

User Guidance Medical judgment should be exercised in completing this data element.
The information provided here describes previous experience with the
drug described in D.8.r.See Section D.8.r. A MedDRA LLT code should
be used.
Conformance Optional, but required if D.8.r.7a is populated.
Data Type 8N
OID 2.16.840.1.113883.6.163
Value Allowed Numeric
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-88-
D.9 In Case of Death

D.9.1 Date of Death

User Guidance This data element captures the reported date of death for the patient. An
imprecise date can be used.
Conformance Optional
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
Minimum precision required is the year (i.e. ‘CCYY’).
The date specified cannot refer to a future date.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

D.9.2.r Reported Cause(s) of Death (repeat as necessary)

The designation of ‘r’ in this section indicates that each item is repeatable and that it
corresponds to the same ‘r’ in all subsections. A separate block (r) should be used for each
cause of death term. For example, if two causes of death are reported, the first cause would be
described in items D.9.2.1.1 through D.9.2.1.2 and the other cause would be described in items
D.9.2.2.1 through D.9.2.2.2.

D.9.2.r.1a MedDRA Version for Reported Cause(s) of Death

User Guidance This data element captures the MedDRA version for D.9.2.r.1b.
Conformance Optional, but required if D.9.2.r.1b is populated.
Data Type 4AN
OID None
Value Allowed Numeric and ‘.‘(dot)
Business Rule(s)
Only 1 MedDRA version is allowed per ICSR.
For MedDRA version 15.1 value allowed is ‘15.1’.

D.9.2.r.1b Reported Cause(s) of Death (MedDRA code)

User Guidance This data element captures the MedDRA LLT code for the reported cause
of death.
Conformance Optional, but required if D.9.2.r.1a is populated.
Data Type 8N
OID 2.16.840.1.113883.6.163
Value Allowed Numeric
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-89-
D.9.2.r.2 Reported Cause(s) of Death (free text)

User Guidance This data element captures the original reporter's words and/or short
phrases used to describe the cause of death. Text should be provided in an
English translation for international transmission.
Conformance Optional, but required if D.9.2.r.1 is populated.
Data Type 250AN
OID None
Value Allowed Free text
Business Rule(s)

D.9.3 Was Autopsy Done?

User Guidance This data element indicates if an autopsy was done.

Conformance Optional, but required if D.9.1 is populated.
Data Type Boolean
OID None
Value Allowed false
true
nullFlavor: ASKU, NASK, UNK
Business Rule(s)
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

D.9.4.r Autopsy-determined Cause(s) of Death (repeat as necessary)

D.9.4.r.1a MedDRA Version for Autopsy-determined Cause(s) of Death

User Guidance This data element captures the MedDRA version for D.9.4.r.1b.
Conformance Optional, but required if D.9.4.r.1b is populated.
Data Type 4AN
OID None
Value Allowed Numeric and ‘.‘(dot)
Business Rule(s)
Only 1 MedDRA version is allowed per ICSR.
For MedDRA version 15.1 value allowed is ‘15.1’.

D.9.4.r.1b Autopsy-determined Cause(s) of Death (MedDRA code)

User Guidance This data element captures the MedDRA LLT code for the autopsy-
determined cause of death.
Conformance Optional, but required if D.9.4.r.1a is populated.
Data Type 8N
OID 2.16.840.1.113883.6.163
Value Allowed Numeric
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-90-
D.9.4.r.2 Autopsy-determined Cause(s) of Death (free text)

User Guidance This data element captures the original reporter's words and/or short
phrases used to describe the autopsy-determined cause of death. Text
should be provided in an English translation for international transmission.
Conformance Optional, but required if D.9.4.r.1 is populated.
Data Type 250AN
OID None
Value Allowed Free text
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-91-
D.10 FOR A PARENT-CHILD / FOETUS REPORT, INFORMATION
CONCERNING THE PARENT

This section should be used in the case of a parent-child/foetus report where the parent had no
reaction/event. Otherwise, this section should not be used. See the user guidance for Section
D.

D.10.1 Parent Identification

User Guidance See the user guidance for D.1.
Conformance Optional
Data Type 60AN
OID None
Value Allowed Free text
nullFlavor: MSK, ASKU, NASK, UNK
Business Rule(s)
If the name or initials of the parent are unknown to the sender, this data
element should be left blank with nullFlavor=UNK.

If the name or initials are known to the sender but cannot be transmitted
due to data privacy requirements, this data element should be left blank
with nullFlavor=MSK.

Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

D.10.2 Parent Age Information

The parent age at the time of reaction / event to the child / foetus should be used. Select only
one of the data elements from D.10.2.1 or D.10.2.2. The choice should be based upon the most
precise information available and in conformance with the regional confidentiality
requirements.

If the full date of birth is not known, an incomplete date can be used. Alternatively, an
approximate age can be captured in Section D.10.2.2.

D.10.2.1 Date of Birth of Parent

User Guidance This data element captures the date of birth of the parent. An incomplete
date can be used.
Conformance Optional
Data Type Date / Time
OID None
Value Allowed nullFlavor: MSK, ASKU, NASK
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-92-
 Minimum precision required is the year (i.e. ‘CCYY’).
The date specified cannot refer to a future date.
If the date of birth is known to the sender but cannot be transmitted due to
data privacy requirements, this data element should be left blank with
nullFlavor set to ‘MSK’.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

D.10.2.2 Age of Parent

D.10.2.2a Age of Parent (number)

User Guidance This data element captures the age value (quantity) for the parent.
Conformance Optional, but required if D.10.2.2b is populated.
Data Type 3N
OID None
Value Allowed Numeric
Business Rule(s)

D.10.2.2b Age of Parent (unit)

User Guidance This data element captures the unit for the age value in D.10.2.2a.
Conformance Optional, but required if D.10.2.2a is populated.
Data Type 50AN
OID 2.16.840.1.113883.3.989.2.1.1.26
Value Allowed UCUM codes for Year: {Decade}
Business Rule(s)

D.10.3 Last Menstrual Period Date of Parent

User Guidance This data element captures the date of the last menstrual period for the
parent.
Conformance Optional
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
Minimum precision required is the year (i.e. ‘CCYY’).
The date specified cannot refer to a future date.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

D.10.4 Body Weight (kg) of Parent

User Guidance This data element captures the weight of the parent in kilograms.
Conformance Optional
Data Type 6N
OID None

ICH ICSR Implementation Guide 10 November 2016

-93-
 Value Allowed Numeric
Business Rule(s)
Fractions or decimals are allowed using a period. No commas are allowed
in this numeric data element.

D.10.5 Height (cm) of Parent

User Guidance This data element captures the reported height of the parent in centimetres.
Conformance Optional
Data Type 3N
OID None
Value Allowed Numeric
Business Rule(s)
Provide rounded number. No fractions, decimals, and commas are
allowed in this numeric data element

D.10.6 Sex of Parent

User Guidance This data element captures the sex of the parent.
Conformance Required if any data element in D.10 section is populated.
Data Type 1N
OID 1.0.5218
Value Allowed 1=Male
2=Female
nullFlavor: UNK, MSK, ASKU, NASK
Business Rule(s)
If the sex of the parent is known to the sender but cannot be transmitted
due to data privacy requirements, this data element should be left blank
with nullFlavor = MSK.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

D.10.7 Relevant Medical History and Concurrent Conditions of Parent

D.10.7.1.r Structured Information of Parent (repeat as necessary)

D.10.7.1.r.1a MedDRA Version for Medical History

User Guidance This data element provides the MedDRA version for D.10.7.1.r.1b
Conformance Optional, but required if D.10.7.1.r.1b is populated.
Data Type 4AN
OID None
Value Allowed Numeric and ‘.‘(dot)
Business Rule(s)
Only 1 MedDRA version is allowed per ICSR.
For MedDRA version 15.1 value allowed is ‘15.1’.

D.10.7.1.r.1b Medical History (disease / surgical procedure / etc.) (MedDRA code)

User Guidance This data element captures the MedDRA LLT code for the medical
condition of the parent. See Section D.7.1.r.

ICH ICSR Implementation Guide 10 November 2016

-94-
 Conformance Optional, but required if D.10.7.1.r.1a is populated.
Data Type 8N
OID 2.16.840.1.113883.6.163
Value Allowed Numeric
Business Rule(s)

D.10.7.1.r.2 Start Date

User Guidance This data element captures the start date of the medical condition of the
parent.
Conformance Optional
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
Minimum precision required is the year (i.e. ‘CCYY’).
The date specified cannot refer to a future date.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

D.10.7.1.r.3 Continuing

User Guidance This data element indicates if the ‘medical condition’ in D.10.7.1.r is
known to be still present at the time of this report.
Conformance Optional
Data Type Boolean
OID None
Value Allowed false
true
nullFlavor: MSK, ASKU, NASK, UNK
Business Rule(s)
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

D.10.7.1.r.4 End Date

User Guidance This data element captures the stop date of the medical condition of the
parent.
Conformance Optional
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
Minimum precision required is the year (i.e. ‘CCYY’).
The date specified cannot refer to a future date.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

ICH ICSR Implementation Guide 10 November 2016

-95-
D.10.7.1.r.5 Comments

User Guidance This data element provides additional relevant information about the
‘medical condition’ in D.10.7.1.r that could not be captured otherwise in a
structured data element.
Conformance Optional
Data Type 2000AN
OID None
Value Allowed Free text
Business Rule(s)

D.10.7.2 Text for Relevant Medical History and Concurrent Conditions of Parent

User Guidance This data element captures information about any other medical history
for the parent that could not be coded in D.10.7.1.r.
Conformance Optional
Data Type 10000AN
OID None
Value Allowed Free text
Business Rule(s)

D.10.8.r Relevant Past Drug History of Parent (repeat as necessary)

D.10.8.r.1 Name of Drug as Reported

User Guidance This data element captures the name of the medicinal product as reported
by the reporter. It is recognised that a single product can have different
proprietary names in different countries, even when it is produced by a
single manufacturer. See Section D.8.r.
Conformance Optional
Data Type 250AN
OID None
Value Allowed Free text
Business Rule(s)

D.10.8.r.2a MPID Version Date/Number

User Guidance See Section D.8.r.

Conformance Optional
Data Type As per ISO IDMP.
OID None
Value Allowed As per ISO IDMP.

ICH ICSR Implementation Guide 10 November 2016

-96-
 Business Rule(s)

D.10.8.r.2b Medicinal Product Identifier (MPID)

User Guidance See Section D.8.r.

Conformance Optional
Data Type As per ISO IDMP.
OID As per ISO IDMP.
Value Allowed As per ISO IDMP.
Business Rule(s)
Any given drug entry may have either MPID or PhPID, but NOT both.

D.10.8.r.3a PhPID Version Date/Number

User Guidance See Section D.8.r.

Conformance Optional
Data Type As per ISO IDMP.
OID None
Value Allowed As per ISO IDMP.
Business Rule(s)

D.10.8.r.3b Pharmaceutical Product Identifier (PhPID)

User Guidance See Section D.8.r.

Conformance Optional
Not allowed if D.10.8.r.2b is populated.
Data Type As per ISO IDMP.
OID As per ISO IDMP.
Value Allowed As per ISO IDMP.
Business Rule(s)
Any given drug entry may have either MPID or PhPID, but NOT both.

D.10.8.r.4 Start Date

User Guidance This data element captures the start date of relevant past drug history for
the parent.
Conformance Optional
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
nullFlavor: MSK, ASKU, NASK
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-97-
 Minimum precision required is the year (i.e. ‘CCYY’).
The date specified cannot refer to a future date.
Please see Section 3.3.6 for further guidance on the use of
nullFlavor to describe missing or non-transmitted information.

D.10.8.r.5 End Date

User Guidance This data element captures the stop date of relevant past drug history for
the parent.
Conformance Optional
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
Minimum precision required is the year (i.e. ‘CCYY’).
The date specified cannot refer to a future date.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

D.10.8.r.6a MedDRA Version for Indication

User Guidance This data element provides the MedDRA version for D.10.8.r.6b.
Conformance Optional, but required if D.10.8.r.6b is populated.
Data Type 4AN
OID None
Value Allowed Numeric and ‘.‘(dot)
Business Rule(s)
Only 1 MedDRA version is allowed per ICSR.
For MedDRA version 15.1 value allowed is ‘15.1’.

D.10.8.r.6b Indication (MedDRA code)

User Guidance This data element captures the MedDRA LLT code for the indication of
the medicinal product.
Conformance Optional, but required if D.10.8.r.6a is populated.
Data Type 8N
OID 2.16.840.1.113883.6.163
Value Allowed Numeric
Business Rule(s)

D.10.8.r.7a MedDRA Version for Reaction

User Guidance This data element provides the MedDRA version for D.10.8.r.7b

ICH ICSR Implementation Guide 10 November 2016

-98-
 Conformance Optional, but required if D.10.8.r.7b is populated.
Data Type 4AN
OID None
Value Allowed Numeric and ‘.‘(dot)
Business Rule(s)
Only 1 MedDRA version is allowed per ICSR.
For MedDRA version 15.1 value allowed is ‘15.1’.

D.10.8.r.7b Reactions (MedDRA code)

User Guidance Medical judgment should be exercised in completing this data element.
The information provided here describes previous experience of the parent
with the drug described in D.10.8.r.
Conformance Optional, but required if D.10.8.r.7a is populated.
Data Type 8N
OID 2.16.840.1.113883.6.163
Value Allowed Numeric
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-99-
E.i REACTION(S)/EVENT(S) (REPEAT AS NECESSARY)

A minimum of one reaction/event needs to be provided for each valid ICSR. The designation of
‘i’ in this section indicates that each item is repeatable and that it corresponds to the same ‘i’ in
all subsections.

For technical reason, each reaction / event should be assigned an internal ID so that
G.k.9.i.1 can refer to the reaction / event from the drug / event matrix.

A separate block (i) should be used for each reaction/event term. For example, if two
reactions are observed, the first reaction would be described in items E.1.1 through
E.1.9, and the other reaction would be described in items E.2.1 through E.2.9.

E - Reaction(s)/Event(s)
1…n

E.i - Reaction(s)/Event(s) (repeat as necessary)

E.i.1.1a - Reaction / Event as Reported by the Primary Source in Native Language

E.i.1.1b - Reaction / Event as Reported by the Primary Source Language
E.i.1.2 - Reaction / Event as Reported by the Primary Source for Translation
E.i.2.1a - MedDRA Version for Reaction / Event
E.i.2.1b - Reaction / Event (MedDRA code)
E.i.3.1 - Term Highlighted by the Reporter
E.i.3.2 - Seriousness Criteria at Event Level
E.i.3.2a - Results in Death
E.i.3.2b - Life Threatening
E.i.3.2c - Caused / Prolonged Hospitalisation
E.i.3.2d - Disabling / Incapacitating
E.i.3.2e - Congenital Anomaly / Birth Defect
E.i.3.2f - Other Medically Important Condition
E.i.4 - Date of Start of Reaction / Event
E.i.5 - Date of End of Reaction / Event
E.i.6a - Duration of Reaction / Event
E.i.6b - Duration of Reaction / Event (duration unit)
E.i.7 - Outcome of Reaction / Event at the Time of Last Observation
E.i.8 - Medical Confirmation by Healthcare Professional
E.i.9 - Identification of the Country Where the Reaction / Event Occurred

ICH ICSR Implementation Guide 10 November 2016

-100-
E.i.1 Reaction / Event as Reported by the Primary Source

E.i.1.1a Reaction / Event as Reported by the Primary Source in Native Language

User Guidance This data element captures the original reporter's words and/or short
phrases used to describe the reaction/event. Text should be provided in
the native language it was received, when it is received in a language
other than English.
Conformance Optional
Data Type 250AN
OID None
Value Allowed Free text
Business Rule(s)

E.i.1.1b Reaction / Event as Reported by the Primary Source Language

User Guidance Provide the language used in E.i.1.1a by using an International

Standard, Codes for the representation of names of languages-- Part 2:
alpha-3 code.
Conformance Optional, but required if E.i.1.1a is populated.
Data Type 3A
OID 2.16.840.1.113883.6.100
Value Allowed ISO 639-2/RA, alpha-3
Business Rule(s)

E.i.1.2 Reaction / Event as Reported by the Primary Source for Translation

User Guidance This data element captures the original reporter's words and/or short
phrases used to describe the reaction/event should be provided in an
English translation for international transmission.
Conformance Optional
Data Type 250AN
OID None
Value Allowed Free text
Business Rule(s)

E.i.2.1a MedDRA Version for Reaction / Event

User Guidance This data element provides the MedDRA version for E.i.2.1b.
Conformance Required
Data Type 4AN
OID None
Value Allowed Numeric and ‘.‘(dot)
Business Rule(s)
Only 1 MedDRA version is allowed per ICSR.
For MedDRA version 15.1 value allowed is ‘15.1’.

ICH ICSR Implementation Guide 10 November 2016

-101-
E.i.2.1b Reaction / Event (MedDRA code)
User Guidance This data element captures the MedDRA LLT most closely corresponding
to the reaction/event as reported by the primary source. In the exceptional
circumstance when a MedDRA term cannot be found, the sender should
use clinical judgment to complete this item with the best MedDRA
approximation (See MedDRA Term Selection: Points to Consider).
Conformance Required
Data Type 8N
OID 2.16.840.1.113883.6.163
Value Allowed Numeric
Business Rule(s)

E.i.3.1 Term Highlighted by the Reporter

User Guidance A highlighted term is a reaction/event that the primary source indicated
was a major concern or reason for reporting the case. If the information is
not explicitly provided by the initial reporter the term should not be
considered a highlighted term. This data element should be populated
only if the medical concept conveyed in E.i.1 is consistent with the reason
why the reporter contacted the sender. For example, this data element can
be used to indicate the specific diagnosis that was identified by the
reporter. Suppose the reporter specifies flu-like syndrome comprising of
fever, chills, sneezing, myalgia and headache, then flu-like syndrome is the
highlighted term. If only one event is cited in a case report, this one is by
implication considered highlighted by the reporter.
It is assumed that the event seriousness is provided by the reporter;
otherwise, it is assessed by the sender.
Conformance Optional
Data Type 1N
OID 2.16.840.1.113883.3.989.2.1.1.10
Value Allowed 1 = Yes, highlighted by the reporter, NOT serious
2 = No, not highlighted by the reporter, NOT serious
3 = Yes, highlighted by the reporter, SERIOUS
4 = No, not highlighted by the reporter, SERIOUS
Business Rule(s)
See E.i.3.2 for the ‘seriousness’ assessment of the highlighted term.

E.i.3.2 Seriousness Criteria at Event Level

The seriousness criteria of the reaction/event should be based on the definitions provided in the
ICH E2A and E2D guidelines. More than one seriousness criteria can be chosen. If the event is
not serious, all of these data elements should be left blank. It is assumed that the event
seriousness is provided by the reporter; otherwise, it is assessed by the sender.

In cases of foetal demise such as miscarriage, (where the ICSR should be prepared only for the
parent), the seriousness criterion is ‘Other medically important condition’. Furthermore,
depending if the parent experienced complications, the seriousness criterion could also include
‘life-threatening’ and/or ‘hospitalisation’.

ICH ICSR Implementation Guide 10 November 2016

-102-
E.i.3.2a Results in Death

User Guidance See Section E.i.3.2.

Conformance Required
Data Type Boolean
OID None
Value Allowed true
nullFlavor: NI
Business Rule(s)

E.i.3.2b Life Threatening

User Guidance See Section E.i.3.2.

Conformance Required
Data Type Boolean
OID None
Value Allowed true
nullFlavor: NI
Business Rule(s)

E.i.3.2c Caused / Prolonged Hospitalisation

User Guidance See Section E.i.3.2.

Conformance Required
Data Type Boolean
OID None
Value Allowed true
nullFlavor: NI
Business Rule(s)

E.i.3.2d Disabling / Incapacitating

User Guidance See Section E.i.3.2.

Conformance Required
Data Type Boolean
OID None
Value Allowed true
nullFlavor: NI
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-103-
E.i.3.2e Congenital Anomaly / Birth Defect

User Guidance See Section E.i.3.2.

Conformance Required
Data Type Boolean
OID None
Value Allowed true
nullFlavor: NI
Business Rule(s)

E.i.3.2f Other Medically Important Condition

User Guidance See Section E.i.3.2.

Conformance Required
Data Type Boolean
OID None
Value Allowed true
nullFlavor: NI
Business Rule(s)

E.i.4 Date of Start of Reaction / Event

User Guidance This data element captures the date of the start of the reaction/event.
When multiple terms are reported (e.g. diagnosis with signs and
symptoms) and the reporter does not provide a specific onset date for each
reaction/event, this data element should be populated with the start date of
the first symptom.
Conformance Optional
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
Minimum precision required is the year (i.e. ‘CCYY’).
The date specified cannot refer to a future date.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

ICH ICSR Implementation Guide 10 November 2016

-104-
E.i.5 Date of End of Reaction / Event
User Guidance This data element captures the date the reaction/event is reported as
resolved/recovered or resolved/recoveredwithsequelae (E.i.7).

When multiple terms are reported (e.g. diagnosis with signs and
symptoms) and the reporter does not provide a specific stop date for each
reaction/event, this data element should be populated with the end date of
the last symptom.
Conformance Optional
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
nullFlavor: MSK, ASKU, NASK
Business Rule(s)
Minimum precision required is the year (i.e. ‘CCYY’).
The date specified cannot refer to a future date.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

E.i.6a Duration of Reaction / Event (number)

User Guidance This section will usually be computed from the start/end date and time of
the reaction/event. However, there might be situations in which the
precise duration of the reaction/event and date can be useful, such as for a
reaction/event of short duration such as anaphylaxis or arrhythmia. In
such a case, populate 1 data element for the date (start or end date) and
this data element. This data element captures the value (quantity) for the
duration of the reaction.
Conformance Optional, but required if E.i.6b is populated.
Data Type 5N
OID None
Value Allowed Numeric
Business Rule(s)

E.i.6b Duration of Reaction / Event (unit)

User Guidance This data element captures the unit of time for the value recorded in
E.i.6a.
Conformance Optional, but required if E.i.6a is populated.
Data Type 50AN
OID 2.16.840.1.113883.3.989.2.1.1.26
Value Allowed Constrained UCUM codes
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-105-
E.i.7 Outcome of Reaction / Event at the Time of Last Observation
User Guidance This data element captures the latest outcome of the reaction / event at the
time of the report.

In case of irreversible congenital anomalies, the choice not recovered/not

resolved/ongoing should be used. For other irreversible medical
conditions, recovered/resolved with sequelae should be used.

Fatal should be used when death is possibly related to the reaction/event.

Considering the difficulty of deciding between ‘reaction/event caused
death’ and ‘reaction/event contributed significantly to death’, both
concepts are grouped in a single category. Where the death is unrelated to
the reaction/event, according to both the reporter and the sender, ‘fatal’
should NOT be selected here; nevertheless, death should be reported
under Section D.9.
Conformance Required
Data Type 1N
OID 2.16.840.1.113883.3.989.2.1.1.11
Value Allowed 1 = recovered/resolved
2 = recovering/resolving
3 = not recovered/not resolved/ongoing
4 = recovered/resolved with sequelae
5 = fatal
0 = unknown
Business Rule(s)

E.i.8 Medical Confirmation by Healthcare Professional

User Guidance If an event is reported by a non-healthcare professional (e.g. lawyers,
consumers), this data element indicates whether the occurrence of the
event was subsequently confirmed by a healthcare professional. If the
healthcare professional also provides an assessment of causality (related
or not to the suspect drug), that should be recorded in G.k.9.
Conformance Optional
Data Type Boolean
OID None
Value Allowed false
true
Business Rule(s)
‘False’ means the event is not confirmed, it does not mean the event did
not occur. If the event is reported by a healthcare professional, this is not
transmitted.

ICH ICSR Implementation Guide 10 November 2016

-106-
E.i.9 Identification of the Country Where the Reaction / Event Occurred
User Guidance This data element captures the country where the reaction occurred. For
example a patient living in Country A experienced headache while
travelling in Country B; this headache was suspected to be an adverse
drug reaction and was reported by a health professional in Country C.
The data element C.2.r.3 should be populated with Country C, and the
data element E.i.9 should be populated with Country B.
Conformance Optional
Data Type 2A
OID 1.0.3166.1.2.2
Value Allowed ISO 3166-1 alpha-2, EU
Business Rule(s)
A two character country code will be used in all instances.
The country code EU exists in the ISO 3166 country code list as an
exceptional reservation code to support any application that needs to
represent the name European Union.In this case, ‘EU’ will be accepted as
the country code.

F.r Results of Tests and Procedures Relevant to the Investigation of the Patient (repeat as
necessary)

This section captures the tests and procedures performed to diagnose or confirm the
reaction/event, including those tests done to investigate (exclude) a non-drug cause (e.g.
serologic tests for infectious hepatitis in suspected drug-induced hepatitis). Both positive and
negative results should be reported. While structured information is preferable, provisions are
made to transmit the information as free text.

The designation of ‘r’ in this section indicates that each item is repeatable and that it
corresponds to the same ‘r’ in all subsections. A separate block (r) should be used for each
test/procedure. For example, if two tests are reported, the first test would be described in items
F.1.1 through F.1.7, and the other test would be described in items F.2.1 through F.2.7.

ICH ICSR Implementation Guide 10 November 2016

-107-
 F - Results of Tests and Procedures Relevant to the Investigation of the Patient
0…n
F.r - Results of Tests and Procedures Relevant to the Investigation of the Patient
(repeat as necessary)

F.r.1 - Test Date

F.r.2.1 - Test Name (free text)
F.r.2.2a - MedDRA Version for Test Name
F.r.2.2b - Test Name (MedDRA code)
F.r.3.1 - Test Result (code)
F.r.3.2 - Test Result (value/qualifier)
F.r.3.3 - Test Result (unit)
F.r.3.4 - Result Unstructured Data (free text)
F.r.4 - Normal Low Value
F.r.5 - Normal High Value
F.r.6 - Comments (free text)
F.r.7 - More Information Available

F.r.1 Test Date

User Guidance This data element captures the date of the test or procedure. Imprecise
dates can be used.
Conformance Optional, but required if F.r.2 is populated.
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
nullFlavor = UNK
Business Rule(s)
Minimum precision required is the year (i.e. ‘CCYY’).
The date specified cannot refer to a future date.
If the test date is unknown, use NullFlavor =UNK.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

F.r.2 Test Name

F.r.2.1 Test Name (free text)

User Guidance This data element captures a free text description of the test when an
appropriate MedDRA code is unavailable.
Conformance Optional, but required if F.r.1 is populated and F.r.2.2b is not populated.
Data Type 250AN
OID None
Value Allowed Free text
Business Rule(s)

F.r.2.2a MedDRA Version for Test Name

ICH ICSR Implementation Guide 10 November 2016

-108-
 User Guidance This data element provides the MedDRA version for F.r.2.2b.
Conformance Optional, but required when F.r.2.2b is populated.
Data Type 4AN
OID None
Value Allowed Numeric and ‘.‘(dot)
Business Rule(s)
Only 1 MedDRA version is allowed per ICSR.
For MedDRA version 15.1 value allowed is ‘15.1’.

F.r.2.2b Test Name (MedDRA code)

User Guidance This data element captures the MedDRA LLT code for the test name.
Conformance Optional, but required when F.r.1 is populated and F.r.2.1 is not
populated.
Data Type 8N
OID 2.16.840.1.113883.6.163
Value Allowed Numeric
Business Rule(s)

F.r.3 Test Result

A Test Result is required for each F block. When a numeric value cannot be used to describe
the result, provisions are made to use a controlled vocabulary. If results and units cannot be
split, F.r.3.4 should be used.

F.r.3.1 Test Result (code)

User Guidance This data element allows a descriptive code to indicate the test result.
Conformance Optional, but required if F.r.2 is populated, and neither F.r.3.2 nor F.r.3.4
is populated.
Data Type 1N
OID 2.16.840.1.113883.3.989.2.1.1.12
Value Allowed 1=Positive
2=Negative
3=Borderline
4=Inconclusive
Business Rule(s)
This data element can be used when a numeric value cannot describe the
result.

ICH ICSR Implementation Guide 10 November 2016

-109-
F.r.3.2 Test Result (value / qualifier)

User Guidance This data element captures the value (amount) for the test result. The
supported qualifiers are ‘greater than’, ‘less than’, ‘greater than or equal
to’ and ‘less than or equal to’. See Appendix I (G) to the IG for XML
examples of expression of qualifiers using nullFlavors.
Conformance Optional, but required if F.r.2 is populated, and F.r.3.1 and F.r.3.4 is not
populated.
Data Type 50N
OID None
Value Allowed Numeric
nullFlavor: NINF, PINF
Business Rule(s)
If results and units cannot be split, F.r.3.4 should be used.

F.r.3.3 Test Result (unit)

User Guidance This data element captures the unit for the test value. When a UCUM
code is not suitable, or results (F.r.3.2) and units (F.r.3.3) cannot be split,
F.r.3.4 should be used.
Conformance Optional, but required if F.r.3.2 is populated.
Data Type 50AN
OID 2.16.840.1.113883.6.8
Value Allowed UCUM
Business Rule(s)
Constrained UCUM is not provided for this unit. Select most appropriate
unit from UCUM codes.

F.r.3.4 Result Unstructured Data (free text)

User Guidance This data element is used when ‘results’ and ‘units’ cannot be split, often
because a UCUM code is not available for the test unit. For example, for
the test ‘protein excretion’, the result could be recorded here as ‘125mg /
24 hours’.
Conformance Optional, but required if F.r.2 is populated, and F.r.3 is not populated.
Data Type 2000AN
OID None
Value Allowed Free text
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-110-
F.r.4 Normal Low Value
User Guidance This data element captures the ‘lowest’ value in the normal range for the
test. This value is usually published by the laboratory providing the test
results. The same units as used in F.r.3.3 are implied.
Conformance Optional
Data Type 50AN
OID None
Value Allowed Free text
Business Rule(s)
The value will be transmitted as physical quantity (PQ) as separate
amount and unit and following line indicates this value is normal low
value:
<valuexsi:type="PQ" value="40" unit="mg/dl"/>
<interpretationCode code="L"codeSystem="2.16.840.1.113883.5.83"/>

F.r.5 Normal High Value

User Guidance This data element captures the ‘highest’ value in the normal range for the
test. This value is usually published by the laboratory providing the test
results. The same units as used in F.r.3.3 are implied.
Conformance Optional
Data Type 50AN
OID None
Value Allowed Free text
Business Rule(s)
The value will be transmitted as physical quantity (PQ) as separate
amount and unit and following line indicates this value is normal high
value :
<valuexsi:type="PQ" value="80" unit="mg/dl"/>
<interpretationCode code="H"codeSystem="2.16.840.1.113883.5.83"/>

F.r.6 Comments (free text)

User Guidance This data element captures any relevant comments made by the reporter
about the test result.
Conformance Optional
Data Type 2000AN
OID None
Value Allowed Free text
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-111-
F.r.7 More Information Available
User Guidance This data element indicates if more information is held by the sender
about the test and test result. For example, ‘true’ means that more
documentation is available upon request e.g. ECG strips, chest X-ray.
‘False’ means that no more documentation is available from the sender.

If this data element is set to ‘true’, then C.1.6.1 should be set to ‘true’.
Conformance Optional
Data Type Boolean
OID None
Value Allowed false
true
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-112-
G.k DRUG(S) INFORMATION (REPEAT AS NECESSARY)

This section covers both suspect and concomitant medications (including biologics) including
drugs suspected to have a type of interaction (e.g. drug, food, tobacco, etc).A minimum of one
suspect medication needs to be provided for each valid ICSR. Medications used to treat the
reaction/event should not be included here.

For each drug, the ‘Characterisation of the Drug Role’ (G.k.1) is the one reported or implied by
the primary reporter (e.g. the original source of the information).Suspect medications are those
health products taken by the patient and suspected by the reporter to have contributed to the
adverse reaction described in Section E. The suspect medication might have been stopped
before the reaction is observed, for example, a single dose of an antibiotic could be suspected to
cause diarrhoea one week later. However, concomitant medications are only those health
products taken by the patient at the time the reaction is observed; other relevant medication
history should be recorded in Section D.8.

As for the designation ‘i’ in Section E above, the designation of ‘k’ in this section indicates that
each item is repeatable and that it corresponds to the same ‘k’ in all subsections. A separate
block (k) should be used for each health product. Within a block (k), subsections can also
repeat using the designation ‘r’, and within a subsection (r), further sub-subsections can repeat
using the designation ‘i’.

The designation of ‘k’ in this section indicates that each item is repeatable and that
it corresponds to the same ‘k’ in all subsections. A separate block (k) should be
used for each drug. Drugs used to treat the reaction/event should not be included
here.

ICH ICSR Implementation Guide 10 November 2016

-113-
 G - Drug(s) Information
1…n
G.k - Drug(s) Information

G.k.1 - Characterisation of Drug Role

G.k.2.1.1a - MPID Version Date / Number
G.k.2.1.1b - Medicinal Product Identifier (MPID)
G.k.2.1.2a - PhPID Version Date / Number
G.k.2.1.2b - Pharmaceutical Product Identifier (PhPID)
G.k.2.2 - Medicinal Product Name as Reported by the Primary Source
G.k.2.4 - Identification of the Country Where the Drug Was Obtained
G.k.2.5 - Investigational Product Blinded
G.k.3.1 - Authorisation / Application Number
G.k.3.2 - Country of Authorisation / Application
G.k.3.3 - Name of Holder / Applicant
G.k.5a - Cumulative Dose to First Reaction (number)
G.k.5b - Cumulative Dose to First Reaction (unit)
G.k.6a - Gestation Period at Time of Exposure (number)
G.k.6b - Gestation Period at Time of Exposure (unit)
G.k.8 - Action(s) Taken with Drug
G.k.11 - Additional Information on Drug (free text)

G.k.2.3.r - Substance/Specified Substance Identifier and Strength (repeat as necessary)

0…n G.k.2.3.r.1 - Substance/ Specified Substance Name

G.k.2.3.r.2a - Substance/Specified Substance TermID Version Date / Number
G.k.2.3.r.2b - Substance/Specified Substance TermID
G.k.2.3.r.3 - Strength (number)
G.k.2.3.r.4 - Strength (unit)

G.k.4.r - Dosage Information (repeat as necessary)

0…n G.k.4.r.1a - Dose (number)

G.k.4.r.1b - Dose (unit)
G.k.4.r.2 - Number of Units in the Interval
G.k.4.r.3 - Definition of the Time Interval Unit
G.k.4.r.4 - Date and Time of Start of Drug
G.k.4.r.5 - Date and Time of Last Administration
G.k.4.r.6a - Duration of Drug Administration (number)
G.k.4.r.6b - Duration of Drug Administration (unit)
G.k.4.r.7 - Batch / Lot Number
G.k.4.r.8 - Dosage Text
G.k.4.r.9.1 - Pharmaceutical Dose Form (free text)
G.k.4.r.9.2a - Pharmaceutical Dose Form TermID Version Date / Number
G.k.4.r.9.2b - Pharmaceutical Dose Form TermID
G.k.4.r.10.1 - Route of Administration (free text)
G.k.4.r.10.2a - Route of Administration TermID Version Date / Number
G.k.4.r.10.2b - Route of Administration TermID
G.k.4.r.11.1 - Parent Route of Administration (free text)
G.k.4.r.11.2a - Parent Route of Administration TermID Version Date / Number
G.k.4.r.11.2b - Parent Route of Administration TermID

Continued on Next Page

ICH ICSR Implementation Guide 10 November 2016

-114-
 G - Drug(s) Information

Continued from Previous Page

G.k.7.r - Indication for Use in Case (repeat as necessary)

0…n G.k.7.r.1 - Indication as Reported by the Primary Source

G.k.7.r.2a - MedDRA Version for Indication
G.k.7.r.2b - Indication (MedDRA code)

G.k.9.i - Drug-reaction(s) / Event(s) Matrix (repeat as necessary)

0…n G.k.9.i.1 - Reaction(s) / Event(s) Assessed

G.k.9.i.3.1a - Time Interval between Beginning of Drug Administration and Start of Reaction /
Event (number)
G.k.9.i.3.1b - Time Interval between Beginning of Drug Administration and Start of Reaction /
Event (unit)
G.k.9.i.3.2a - Time Interval between Last Dose of Drug and Start of Reaction / Event (number)
G.k.9.i.3.2b - Time Interval between Last Dose of Drug and Start of Reaction / Event (unit)
G.k.9.i.4 - Did Reaction Recur on Re-administration?

G.k.9.i.2.r - Assessment of Relatedness of Drug to reaction(s)/Event(s)

(repeat as necessary)
0…n G.k.9.i.2.r.1 - Source of Assessment
G.k.9.i.2.r.2 - Method of Assessment
G.k.9.i.2.r.3 - Result of Assessment

G.k.10.r - Additional Information on Drug (repeat as necessary)

0…n G.k.10.r - Additional Information on Drug (coded)

G.k.1 Characterisation of Drug Role

User Guidance This data element contains the characterisation of the drug role as
provided by the primary reporter or, if this information is missing, by the
sender. All spontaneous reports should have at least one suspect drug
(See Section 3.3.1).

If the reporter indicates a suspected interaction with other drug(s),

‘interacting’ should be selected for all suspected interacting drug(s). If an
interaction is suspected with food or other non-drug compounds,
‘interacting’ should be selected for the suspect drug. For evaluation
purposes, all interacting drugs are considered to be suspect drugs. The
type of interaction (e.g. drug interaction, food interaction, alcohol
interaction, etc.), should be captured with the appropriate MedDRA
LLT(s) in Section E.i Reaction(s) / Event(s) along with any event(s)
resulting from the suspected interaction.

‘Drug not administered’ can be used in two circumstances:

In clinical trial: if the adverse event occurred after the informed consent
was signed but prior to the administration of the study drug (e.g. during
the screening period or the washout procedure), the adverse event should
in general be reported as per the trial procedure. In that case, only
sections G.k.1, G.k.2 and G.k.8 are to be filled out for that Section G. The
information on the suspect cause of the event should be provided in the

ICH ICSR Implementation Guide 10 November 2016

-115-
 narrative H.1. In addition, comments can be provided by the reporter in
H.2 and by the sender in the H.4.
Medication error: if the patient did not receive the actual prescribed drug
but another one, repeatable Sections G should be completed with the
information about the prescribed drug (including the fact that it was not
administered), as well as the information on the dispensed drug as the
‘suspect’ drug. The medication error should be captured with the
appropriate MedDRA LLT code in Section E.i Reaction(s) / Event(s).
Conformance Required
Data Type 1N
OID 2.16.840.1.113883.3.989.2.1.1.13
Value Allowed 1 = Suspect
2 = Concomitant
3 = Interacting
4 = Drug Not Administered
Business Rule(s)
Each ICSR must contain at least one ‘Suspect’, ‘Interacting’ or ‘Drug Not
Administered’.

Suspect medications are those health products taken by the patient and suspected by
the reporter to have contributed to the adverse reaction described in Section E.
Concomitant medications are only those health products taken by the patient at the
time the reaction is observed; other relevant medication history should be recorded
in Section D.8.

G.k.2 Drug Identification

Medicinal product names or active ingredient names should be provided in G.k.2.2 as they were
reported by the primary source. To standardise the identification of medicinal products, ISO
IDMP should be used. When available, the most precise structured information should be
provided when identifying medicinal products and redundant information does not have to be
repeated. For example, if a MPID is provided in G.k.2.1.1, there is no need to provide a PhPID
in G.k.2.1.2. Likewise, if a PhPID is provided, there is no need to provide information for
Substance.

In case of investigational drugs, provide as much information as known in G.k.2.2 and

G.k.2.3.r.1 even if only an abstract code might be known.

If more than one substance name is specified for a drug product, each of them should be
included in this section by repeating the item G.k.2.3 as necessary.

The product name used by the reporter should always be provided.

ICH ICSR Implementation Guide 10 November 2016

-116-
G.k.2.1 Medicinal Product Unique Identifier / Pharmaceutical Product Unique Identifier

G.k.2.1.1a MPID Version Date / Number

User Guidance This data element provides the version date for G.k.2.1.1b.
Conformance Optional
Data Type As per ISO IDMP.
OID None
Value Allowed As per ISO IDMP.
Business Rule(s)

G.k.2.1.1b Medicinal Product Identifier (MPID)

User Guidance This data element captures MPID . If an MPID for the reported
medicinal product is not available, this data element should be left
blank.
Conformance Optional
Data Type As per ISO IDMP.
OID As per ISO IDMP.
Value Allowed As per ISO IDMP.
Business Rule(s)

When a MPID (G.k.2.1.1) is provided, the remainder of Section G.k.2.1 and

G.k.2.3.r (G.k.2.3.r.1 through G.k.2.3.r.3) should be blank.

G.k.2.1.2a PhPID Version Date/Number

User Guidance This data element providesthe version date for G.k.2.1.2b.
Conformance Optional
Data Type As per ISO IDMP.
OID None
Value Allowed As per ISO IDMP.
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-117-
G.k.2.1.2b Pharmaceutical Product Identifier (PhPID)

User Guidance This data element captures PhPID. If a PhPID for the reported
medicinal product is not available, this data element should be left
blank.
Conformance Optional
Not allowed if G.k.2.1.1 is provided.
Data Type As per ISO IDMP.
OID As per ISO IDMP.
Value Allowed As per ISO IDMP.
Business Rule(s)
Any given drug entry may have either MPID or PhPID, but NOT both.

When a MPID (G.k.2.1.1) is not available but a PhPID (G.k.2.1.2) is provided,

G.k.2.3.r (G.k.2.3.r.1 through G.k.2.3.r.3) should be blank.

G.k.2.2 Medicinal Product Name as Reported by the Primary Source

User Guidance This data element captures the name of the medicinal product as used by
the reporter. It is recognized that a single product can have different
proprietary names in different countries, even when it is produced by a
single manufacturer.
Conformance Required
Data Type 250AN
OID None
Value Allowed Free text
Business Rule(s)

G.k.2.3.r Substance / Specified Substance Identifier and Strength (repeat as necessary)

If either of MPID or PhPID is not available, each active ingredient should be specified
individually by repeating this section. For each active ingredient, ISO IDMP substance /
specified substance TermID should be provided, if available. If the substance / specified
substance TermID is not available, the INN or the active ingredient name or the drug
identification code should be provided.

ICH ICSR Implementation Guide 10 November 2016

-118-
G.k.2.3.r.1 Substance / Specified Substance Name

User Guidance If a ‘Substance Name TermID’ (G.k.2.3.r.2b) is not available, provide a

text description of the substance. A medical device can be described
here.
Conformance Optional
Data Type 250 AN
OID None
Value Allowed Free text
Business Rule(s)

G.k.2.3.r.2a Substance/Specified Substance TermID Version Date/Number

User Guidance This data element provides the version date for the Substance Name
TermID.
Conformance Optional
Data Type As per ISO IDMP.
OID None
Value Allowed As per ISO IDMP.
Business Rule(s)

G.k.2.3.r.2b Substance/Specified Substance TermID

User Guidance If both MPID (G.k.2.1.1) and PhPID (G.k.2.1.2) are unavailable, use the
most appropriate substance identifier. If an identifier is not available,
this data element will be left blank.
Conformance Optional
Data Type As per ISO IDMP.
OID As per ISO IDMP.
Value Allowed As per ISO IDMP.
Business Rule(s)

G.k.2.3.r.3a Strength (number)

User Guidance If PhPID (G.k.2.1.2) is unavailable, this data element provides the lower
numerator of the strength for the substance or if not a range, the
numerator of the strength when known.
Conformance Optional
Data Type 10N
OID None
Value Allowed Numeric
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-119-
G.k.2.3.r.3b Strength (unit)

User Guidance This data element captures the unit for G.k.2.3.r.3a.
Conformance Optional, but required if G.k.2.3.r.3a is populated.
Data Type 50AN
OID 2.16.840.1.113883.3.989.2.1.1.25
Value Allowed Constrained UCUM codes
Business Rule(s)

G.k.2.4 Identification of the Country Where the Drug Was Obtained

User Guidance This data element captures the country where the medicinal was
obtained.
Conformance Optional
Data Type 2A
OID 1.0.3166.1.2.2
Value Allowed ISO 3166-1 alpha-2, EU
Business Rule(s)
A two character country code will be used in all instances.

The country code EU exists in the ISO 3166 country code list as an
exceptional reservation code to support any application that needs to
represent the name European Union.In this case, ‘EU’ will be accepted
as the country code.

Technically, data type of G.k.2.4 is defined as string instead of code by HL7. To

ensure data quality, this IG requires use of ISO country code instead of free text.

ICH ICSR Implementation Guide 10 November 2016

-120-
G.k.2.5 Investigational Product Blinded
User Guidance This data element is applicable only to ICSRs from clinical trials. The
ICH E2A guideline recommends that the case safety reports with
blinded therapy should not be reported. However, if it is important to
exchange a blinded case safety report during a clinical trial, this data
element should be used as follows: until the investigational product is
un-blinded, the status ‘blinded’ should be indicated by using ‘true’ in
this data element. When this data element is ‘true’, Section G.k.2 Drug
Identification should be populated with the characteristics of the
investigational product. When more than one investigational product is
potentially suspect, each suspect product should be represented in
separate G.k blocks. After un-blinding, if appropriate, ‘placebo’ should
be reported in G.k.2.3.r as a suspect drug.
Conformance Optional
Data Type Boolean
OID None
Value Allowed true
Business Rule(s)
The value for this data element should be set to ‘true’ for ICSRs from
clinical trials when the product status is still blinded at the time the
ICSR is created. Otherwise, this data element should not be transmitted.

G.k.3 Holder and Authorisation / Application Number of Drug

If ISO IDMP MPID is not available for the reported medicinal product, the name of the holder
should be provided along with the authorisation or application number in the country where the
drug was obtained when the case report is sent to that country. Pharmaceutical companies
should provide this information for their own suspect drug(s).

G.k.3.1 Authorisation / Application Number

User Guidance If MPID (G.k.2.1.1) is unavailable, This data element captures the
Authorisation or Application number of the medicinal product for the
country where it was obtained when the case report is sent to that
country. Pharmaceutical companies should provide this information at
least for their own suspect drug(s).
Conformance Optional
Data Type 35 AN
OID 2.16.840.1.113883.3.989.2.1.3.4
Value Allowed Free text
Business Rule(s)
The following notation will be used to represent G.k.3.1:
<id extension="authorisation / application number"
root="2.16.840.1.113883.3.989.2.1.3.4"/>

The root indicates the namespace of G.k.3.1, the actual authorisation/

application number is populated at id extension.

ICH ICSR Implementation Guide 10 November 2016

-121-
G.k.3.2 Country of Authorisation / Application

User Guidance If MPID (G.k.2.1.1)is unavailable, this data element captures the
country where the drug was authorised when the case report is sent to
that country if known.
Conformance Optional, but required if G.k.3.1 is provided.
Data Type 2A
OID 1.0.3166.1.2.2
Value Allowed ISO 3166-1 alpha-2, EU
Business Rule(s)
A two character country code will be used in all instances. The country
code EU exists in the ISO 3166 country code list as an exceptional
reservation code to support any application that needs to represent the
name European Union. In this case, ‘EU’ will be accepted as the
country code.

G.k.3.3 Name of Holder / Applicant

User Guidance This data element captures the name of the licence holder as indicated
on the package.
Conformance Optional
Data Type 60AN
OID None
Value Allowed Free text
Business Rule(s)

G.k.4.r Dosage and Relevant Information (repeat as necessary)

Data elements G.k.4.r.1 through G.k.4.r.3 should be used to provide dosage information. For
example, 5mg (in one dose) every other day, subsections G.k.4.r.1 through G.k.4.r.3 would be 5,
mg, 2, day, respectively. In the same way, 50mg daily would be 50, mg, 1, day, respectively.

For multiple dosages within a given interval, a fraction of that interval is given. For example,
5mg four times in one day (QID), subsections G.k.4.r.1 through G.k.4.r.3 would be 5, mg, 0.25,
day, respectively.

For fixed dose combination drugs dose unit (G.k.4.r.1b) should be provided as arbitrary unit
{DF} instead of mg.

In the case of a parent-child/foetus report, the dosage section applies to the known parental
dose. For example, if the mother took the drug(s) suspected of causing adverse reaction(s) in a
nursing infant, then the dosage information (G.k.4.r.1 to G.k.4.r.11.2) relates to how the mother
took the medication(s). If the mother is the source of the suspect drug(s) then the dosage
information reflects how the mother ingested or was administered the drug(s). If a father is the
source of the suspect drug(s) then the additional information on drug (G.k.10) is provided. The
case narrative (H.1) should describe the entire case, including the father’s information.

ICH ICSR Implementation Guide 10 November 2016

-122-
For a dosage regimen that involves more than one dosage form, and where provision of
structured dosage information is not possible, the information should be provided as text in
SectionG.k.4.r.8.

Note: More dosing examples are provided in Appendix I (G)

G.k.4.r.1a Dose (number)

User Guidance This data element captures the value (number) of each administered
dose.
Conformance Optional
Data Type 8N
OID None
Value Allowed Numeric
Business Rule(s)

G.k.4.r.1b Dose (unit)

User Guidance This data element captures the unit for the dose value in G.k.4.r.1a.
Conformance Optional, but required if G.k.4.r.1a is populated.
Data Type 50AN
OID 2.16.840.1.113883.3.989.2.1.1.25
Value Allowed Constrained UCUM codes: {DF}
Business Rule(s)
UCUM allows using non-unit expression for symbols not in UCUM. In
this case, {DF} can be used in XML message.

G.k.4.r.2 Number of Units in the Interval

User Guidance This data element captures the value (amount) for the time interval
between each administered dose (G.k.4.r.1aand G.k.4.r.1b) If either
G.k.4.r.2 or G.k.4.r.3 is unknown, both should be left blank unless the
definition of the time interval unit is ‘cyclical’, ‘as necessary’, or ‘total’.
Conformance Optional
Data Type 4N
OID None
Value Allowed Numeric
Business Rule(s)

G.k.4.r.3 Definition of the Time Interval Unit

ICH ICSR Implementation Guide 10 November 2016

-123-
 User Guidance This data element captures the UCUM code that best describes the unit
for the dosing time interval (G.k.4.r.2).When a specific time interval for
drug administration is not known, but is confirmed that the drug is used
cyclically or as necessary, then ‘Cyclical’ or ‘As Necessary’ can be used
in this data element. When the total amount of a drug is provided
without any particular dose and dosing interval (e.g. in the case of an
overdose), the quantity and unit (G.k.4.r.1a and G.k.4.r.1b) is provided
along with ‘Total’ in this data element (G.k.4.r.2 is left blank).
Conformance Optional, but required if G.k.4.r.2 is populated.
Data Type 50AN
OID 2.16.840.1.113883.3.989.2.1.1.26
Value Allowed Constrained UCUM codes:{cyclical}, {asnecessary},{total}
Business Rule(s)
UCUM allows using non-unit expression for symbols not in UCUM. In
this case, {cyclical}, {as necessary}, and {total} can be used in XML
message.

G.k.4.r.4 Date and Time of Start of Drug

User Guidance This data element captures the date and time when drug administration
started.
Conformance Optional
Data Type Date / Time
OID None
Value Allowed nullFlavor: MSK, ASKU, NASK
Business Rule(s)
Minimum precision required is the year (i.e. ‘CCYY’).
The date specified cannot refer to a future date. Please see Section 3.3.6
for further guidance on the use of nullFlavor to describe missing or non-
transmitted information.

G.k.4.r.5 Date and Time of Last Administration

User Guidance This data element captures the date and time when drug administration
ended. For ongoing drug administration after the onset of the
reaction/event, this item should be blank and the ‘Action(s) Taken with
Drug’ (G.k.8) should be used. If drug administration is stopped but the
date is unknown, apply the appropriate nullFlavor to G.k.4.r.5.
Conformance Optional
Data Type Date / Time
OID None
Value Allowed nullFlavor: MSK, ASKU, NASK
Business Rule(s)
Minimum precision required is the year(i.e. ‘CCYY’).The date specified
cannot refer to a future date.
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

G.k.4.r.6a Duration of Drug Administration (number)

ICH ICSR Implementation Guide 10 November 2016

-124-
 User Guidance This section will usually be computed from the start/end date and time
of the administration. However, there might be situations in which the
precise duration of the drug administration can be useful, such as
minutes or hours. Also, this item should be used in addition to dates if
exact dates of drug administration are not available at the time of the
report, but there is information concerning the duration of drug
administration. In such a case, populate 1 data element for the date
(start or end date) and this Section. The information requested is the
overall duration of drug administration and covers intermittent
administration. This data element captures the value (quantity) for the
duration of the administration.
Conformance Optional, but required if G.k.4.r.6b is populated.
Data Type 5N
OID None
Value Allowed Numeric
Business Rule(s)

G.k.4.r.6b Duration of Drug Administration (unit)

User Guidance This data element captures the unit for the ‘Duration of Drug
Administration’ (G.k.4.r.6a).
Conformance Optional, but required if G.k.4.r.6a is populated.
Data Type 50AN
OID 2.16.840.1.113883.3.989.2.1.1.26
Value Allowed Constrained UCUM codes
Business Rule(s)

G.k.4.r.7 Batch / Lot Number

User Guidance This data element captures the batch or lot number for the medicinal
product.This information is particularly important for vaccines and
biologics. The most specific information available should be provided.
For expiration date and other related information, see the Additional
Information on Drug (G.k.11).
Conformance Optional
Data Type 35AN
OID None
Value Allowed Free text
Business Rule(s)

G.k.4.r.8 Dosage Text

User Guidance This data element captures free text information when structured dosage
information is not possible, or to provide more detail on structured
dosage data elements. There is no need to duplicate information
provided in the structured dosage data elements.
Conformance Optional

ICH ICSR Implementation Guide 10 November 2016

-125-
 Data Type 2000AN
OID None
Value Allowed Free text
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-126-
G.k.4.r.9 Pharmaceutical Dose Form

G.k.4.r.9.1 Pharmaceutical Dose Form (free text)

User Guidance This data element captures a free text description of the pharmaceutical
dose form when the ‘Pharmaceutical Dose Form TermID’ (G.k.4.r.9.2b)
is not available.
Conformance Optional
Data Type 60 AN
OID None
Value Allowed Free text
nullFlavor: ASKU, NASK, UNK
Business Rule(s)
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

G.k.4.r.9.2a Pharmaceutical Dose Form TermID Version Date/Number

User Guidance This data element provides the version date for the Pharmaceutical Dose
Form TermID.
Conformance Optional
Data Type As per ISO IDMP.
OID None
Value Allowed As per ISO IDMP.
Business Rule(s)

G.k.4.r.9.2b Pharmaceutical Dose Form TermID

User Guidance If PhPID (G.k.2.1.2) is unavailable, the pharmaceutical dose form

should be provided as a ISO IDMP TermID using the Pharmaceutical
Dose Form controlled vocabulary. If the Pharmaceutical Dose Form
TermID is not available, free text in G.k.4.r.9.1 should be used.
Conformance Optional
Data Type As per ISO IDMP.
OID As per ISO IDMP.
Value Allowed As per ISO IDMP.
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-127-
G.k.4.r.10 Route of Administration

G.k.4.r.10.1 Route of Administration (free text)

User Guidance This data element captures a free text description of the route of
administration when the ‘Route of Administration TermID’
(G.k.4.r.10.2b) is not available. An appropriate nullFlavor can be used
if the source has not provided or does not know the information.
Conformance Optional
Data Type 60 AN
OID None
Value Allowed Free text
nullFlavor: ASKU, NASK, UNK
Business Rule(s)
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

G.k.4.r.10.2a Route of Administration TermID Version Date / Number

User Guidance This data element provides the version date for the Route of
Administration TermID.
Conformance Optional
Data Type As per ISO IDMP.
OID None
Value Allowed As per ISO IDMP.
Business Rule(s)
Until ISO IDMP TermID is available, use version number in the ICH
E2B(R3) code list 14.

G.k.4.r.10.2b Route of Administration TermID

User Guidance Route of administration should be provided as TermID using Route of

administration controlled vocabulary. Until ISO IDMP TermID is
available, use the existing code list attached in Appendix I (F). No other
identifiers should be used in this data element.

For a parent-child/foetus report, this data element indicates the route of

administration for the child/foetus (patient). This is usually an indirect
exposure, such as transmammary, but can include more usual routes of
administration for other drugs given to the child. The parent’s route of
administration should be provided in G.k.4.r.11.
Conformance Optional
Data Type As per ISO IDMP.
Until ISO IDMP TermID is available, this is 3N.
OID As per ISO IDMP.
Until ISO IDMP TermID is available, use
2.16.840.1.113883.3.989.2.1.1.14.
Value Allowed As per ISO IDMP.
Until ISO IDMP TermID is available, use code list in Appendix I (F).
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-128-
G.k.4.r.11 Parent Route of Administration (in case of a parent child / foetus report)

G.k.4.r.11.1 Parent Route of Administration (free text)

User Guidance This data element captures a free text description of the route of
administration when the ‘Parent Route of Administration TermID’
(G.k.4.r.11.2b) is not available. An appropriate nullFlavor can be used
if the source has not provided or does not know the information.
Conformance Optional
Data Type 60 AN
OID None
Value Allowed Free text
nullFlavor: ASKU, NASK, UNK
Business Rule(s)
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.

G.k.4.r.11.2a Parent Route of Administration TermID Version Date / Number

User Guidance This data element provides the version date for the Route of
Administration TermID.
Conformance Optional
Data Type As per ISO IDMP.
OID None
Value Allowed As per ISO IDMP.
Business Rule(s)

G.k.4.r.11.2b Parent Route of Administration TermID

User Guidance This data element captures the known route of administration of the
drug as taken by the parent for the dosage described in G.k.4.r.1 to
G.k.4.r.3. The parent’s route of administration should be provided as
TermID using Route of administration controlled vocabulary. Until ISO
IDMP TermID is available, use the existing code list attached in
Appendix I (F).No other identifiers should be used in this data element.
Conformance Optional
Data Type As per ISO IDMP.
Until ISO IDMP TermID is available, this is 3N.
OID As per ISO IDMP.
Until ISO IDMP TermID is available, use
2.16.840.1.113883.3.989.2.1.1.14.
Value Allowed As per ISO IDMP.
Until ISO IDMP TermID is available, use code list in Appendix I (F).
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-129-
G.k.5a Cumulative Dose to First Reaction (number)
User Guidance This data element captures the value (amount) cumulative dose
administered until the onset of the first sign, symptom or reaction/event.
Conformance Optional, but required if G.k.5b is populated.
Data Type 10N
OID None
Value Allowed Numeric
Business Rule(s)

G.k.5b Cumulative Dose to First Reaction (unit)

User Guidance This data element captures the unit for the value in G.k.5a.
Conformance Optional, but required if G.k.5a is populated.
Data Type 50AN
OID 2.16.840.1.113883.3.989.2.1.1.25
Value Allowed Constrained UCUM codes: {DF}
Business Rule(s)
UCUM allows using non-unit expression for symbols not in UCUM. In
this case, {DF} can be used in XML message.

G.k.6a Gestation Period at Time of Exposure (number)

User Guidance This data element captures the number for the gestational age at the
time of the earliest exposure.
Conformance Optional, but required if G.k.6b is populated.
Data Type 3N
OID None
Value Allowed Numeric
Business Rule(s)
The gestational age is expressed in terms of days, weeks, months or
trimester (G.k.6b).

G.k.6b Gestation Period at Time of Exposure (unit)

User Guidance This data element captures the unit for the value in G.k.6a.
Conformance Optional, but required if G.k.6a is populated.
Data Type 50AN
OID 2.16.840.1.113883.3.989.2.1.1.26
Value Allowed UCUM codes for Month, Week, and Day:{Trimester}
Business Rule(s)
Units commonly used in clinical practice but not defined in UCUM can
be transmitted using curly braces like e.g. {trimester}.

ICH ICSR Implementation Guide 10 November 2016

-130-
G.k.7.r Indication for Use in Case (repeat as necessary)

G.k.7.r.1 Indication as Reported by the Primary Source

User Guidance This data element captures the original reporter's words and / or short
phrases used to describe the indication for drug use in an English
translation for international transmission. NullFlavors may be used if
the source has not provided or does not know the information,
respectively.
Conformance Optional
Data Type 250AN
OID None
Value Allowed Free text
nullFlavor: ASKU, NASK, UNK
Business Rule(s)
Please see Section 3.3.6 for further guidance on the use of nullFlavor to
describe missing or non-transmitted information.
Please use nullFlavor with original text attribute in XML instance (See
Appendix I (D) the Reference Instance).

G.k.7.r.2a MedDRA Version for Indication

User Guidance This data element provides the MedDRA version for G.k.7.r.2b
Conformance Optional, but required if G.k.7.r.2b is populated.
Data Type 4AN
OID None
Value Allowed Numeric and ‘.‘(dot)
Business Rule(s)
Only 1 MedDRA version is allowed per ICSR.
For MedDRA version 15.1 value allowed is ‘15.1’.

G.k.7.r.2b Indication (MedDRA code)

User Guidance This data element captures the MedDRA LLT code for the indication of
the medicinal product.
Conformance Optional, but required if G.k.7.r.2a is provided.
Data Type 8N
OID 2.16.840.1.113883.6.163
Value Allowed Numeric
Business Rule(s)
If nullFlavor is used in G.k.7.r.1, select an appropriate MedDRA term to
reflect that the indication is not available.

ICH ICSR Implementation Guide 10 November 2016

-131-
G.k.8 Action(s) Taken with Drug
User Guidance This data element captures the action taken with the drug as a result of
the reaction(s) / event(s). The value ‘1’(Drug withdrawn), taken
together with the ‘Outcome of Reaction /Event at the Time of Last
Observation’ (E.i.7), describe the dechallenge. ‘Not applicable’ should
be used in circumstances such as when the patient has died or the
treatment had been completed prior to reaction(s) /event(s) or the
‘Characterisation of Drug Role’ (G.k.1) is ‘Drug Not Administered’.
When ‘Not applicable’ is used, details should be captured in Section H.
Conformance Optional
Data Type 1N
OID 2.16.840.1.113883.3.989.2.1.1.15
Value Allowed Actions taken codes:
1=Drug withdrawn
2=Dose reduced
3=Dose increased
4=Dose not changed
0=Unknown
9=Not applicable
Business Rule(s)

G.k.9.i Drug-reaction(s) / Event(s) Matrix (repeat as necessary)

This section provides the means to transmit the degree of suspected relatedness of the drug (k)
with a suspect role to each reaction(s)/event(s) (i) in Section E. The repeating items (r) are used
to provide the assessment of relatedness by different sources or methods of assessment. For the
purpose of reporting, there is an implied suspicion of causality for spontaneous reports. It is
recognised that information concerning the relatedness, especially for spontaneous reports, is
often subjective and might not be available.

The following example illustrates the functionality contained in this section.

• Assume the patient has had three adverse events: Event1, Event2, and Event3
• The reporter provided assessment of causality for events Event1 and Event2, but not for
Event3. The reporter’s assessment of causality is based on overall impression, which the
sender codes as ‘global introspection’.
• The sender provided two methods of causality assessment, one with an algorithm (coded
algorithm) and the other a Bayesian analysis (coded Bardi).
• From the above there are 2 sets of data for the reporter (2_events X 1_method of
assessment) and 6 sets for the sender (3_events X 2_methods of assessment) for a total 8
sets of data.
The appropriate item with the ‘relatedness’ information is G.k.9.i.2.r.x (where x equals the 3 sub
data elements 1-3). Please note the sub data elements 1-3 are repeatable. For subsection
G.k.9.i.1, a technical reference to the reaction / event in E.i should be used. Subsections
G.k.9.i.2.r.1, G.k.9.i.2.r.2 and G.k.9.i.2.r.3 do not call for a standardised methodology or
vocabulary.

ICH ICSR Implementation Guide 10 November 2016

-132-
 G.k.9.i.1 G.k.9.i.2.r.1 G.k.9.i.2.r.2 G.k.9.i.2.r.3
technical reference to Reporter global introspection related
event 1 in E.i Company algorithm possibly related
Company Bardi 0.76
technical reference to Reporter global introspection not related
event 2 in E.i Company algorithm possibly related
Company Bardi 0.48
technical reference to Company algorithm unlikely related
event 3 in E.i Company Bardi 0.22

If an event is spontaneously reported to a company about a patient who took that

company's drug, and the relationship is unstated, it implies a suspected causal
relationship to the drug. However, data elements G.k.9.i.1 through G.k.9.i.2.r.3
should be left blank unless otherwise required by local regulation.

The company's causality assessment can be captured in data elements G.k.9.i.1

through G.k.9.i.2.r.3. Additionally, the Sender's Comments in Section H.4 can be
used to further elaborate sender’s position or assessment.

Local regulatory requirements regarding expedited and periodic reporting determine

whether inclusion of sponsor assessments is necessary.

G.k.9.i.1 Reaction(s) / Event(s) Assessed

User Guidance This data element captures a technical reference within the message that
is used to identify which reaction / event in Section E.i is being
assessed. This is not a user entered element.
Conformance Optional
Data Type N/A
OID None
Value Allowed N/A
Business Rule(s)
This is not a user entered element.

ICH ICSR Implementation Guide 10 November 2016

-133-
G.k.9.i.2.r Assessment of Relatedness of Drug to Reaction(s) / Event(s) (repeat as
necessary)

G.k.9.i.2.r.1 Source of Assessment

User Guidance This data element indicates the source of the assessment provided in
G.k.9.i.2.r.3.
Conformance Optional
Data Type 60AN
OID None
Value Allowed Free text
Business Rule(s)

G.k.9.i.2.r.2 Method of Assessment

User Guidance This data element indicates the method of the assessment provided in
G.k.9.i.2.r.3.For example global introspection, algorithm, Bayesian
calculation, etc.
Conformance Optional
Data Type 60AN
OID None
Value Allowed Free text
Business Rule(s)

G.k.9.i.2.r.3 Result of Assessment

User Guidance This data element capturesthe result of the assessment for relatedness.
The ‘value’ will depend on the method used for the assessment.
Conformance Optional
Data Type 60AN
OID None
Value Allowed Free text
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-134-
G.k.9.i.3.1a Time Interval between Beginning of Drug Administration and Start of
Reaction / Event (number)

User Guidance This data element captures the value (amount) for the interval of time
between the start of drug administration and the onset of the reaction.
Even when other dates are provided, this data element is useful also to
be transmitted for circumstances where, for example the interval is very
short minutes, such as in anaphylaxis, or in which only imprecise dates
are known but more information concerning the interval is known. If
the sender wants to provide time intervals as well as dates, then the date
of the first day of administration should be counted as Day 1 of the
interval.
Conformance Optional, but required if G.k.9.i.3.1b is populated.
Data Type 5N
OID None
Value Allowed Numeric
Business Rule(s)

G.k.9.i.3.1b Time Interval between Beginning of Drug Administration and Start of

Reaction / Event (unit)

User Guidance This data element captures the unit for the value in G.k.9.i.3.1a.
Conformance Optional, but required if G.k.9.i.3.1a is populated.
Data Type 50AN
OID 2.16.840.1.113883.3.989.2.1.1.26
Value Allowed Constrained UCUM codes
Business Rule(s)

G.k.9.i.3.2a Time Interval between Last Dose of Drug and Start of Reaction / Event
(number)

User Guidance This data element captures the value (amount) for the interval of time
between the end of drug administration and the onset of the reaction.
Even when other dates are provided, this data element is useful also to
be transmitted for circumstances where, for e.g. the interval is very short
minutes, such as in anaphylaxis, or in which only imprecise dates are
known but more information concerning the interval is known. If the
sender wants to provide time intervals as well as dates, then the date of
the last day of administration should be counted as Day 1 of the interval.
Conformance Optional, but required if G.k.9.i.3.2b is populated.
Data Type 5N
OID None
Value Allowed Numeric
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-135-
G.k.9.i.3.2b Time Interval between Last Dose of Drug and Start of Reaction / Event (unit)

User Guidance This data element capturesthe unit for the value in G.k.9.i.3.2a.
Conformance Optional, but required if G.k.9.i.3.2a is populated.
Data Type 50AN
OID 2.16.840.1.113883.3.989.2.1.1.26
Value Allowed Constrained UCUM codes
Business Rule(s)

G.k.9.i.4 Did Reaction Recur on Re-administration?

User Guidance This data element indicates both if the patient was rechallenged with the
drug and the known outcome. This data element should not be coded if
it was not reported whether or not a rechallenge was done.
Conformance Optional
Data Type 1N
OID 2.16.840.1.113883.3.989.2.1.1.16
Value Allowed 1=yes – yes (rechallenge was done, reaction recurred)
2=yes – no (rechallenge was done, reaction did not recur)
3=yes – unk (rechallenge was done, outcome unknown)
4=no – n/a (no rechallenge was done, recurrence is not applicable)
Business Rule(s)
If the sender does not know whether a rechallenge was performed, this
data element should not be transmitted.

G.k.10.r Additional Information on Drug (coded) (repeat as necessary)

User Guidance This data element capturesany additional information pertinent to the
case that is not covered by the sections above. For example, cases
where the suspect drug was taken by the father, this should be indicated
in this data element as ‘3’ (Drug taken by the father). If the additional
information cannot be described by G.k.10.r,then use the data element
G.k.11.
Conformance Optional
Data Type 2N
OID 2.16.840.1.113883.3.989.2.1.1.17
Value Allowed 1=Counterfeit
2=Overdose
3=Drug taken by the father
4=Drug taken beyond expiry date
5=Batch and lot tested and found within specifications
6=Batch and lot tested and found not within specifications
7=Medication error
8=Misuse
9=Abuse
10=Occupational exposure
11=Off label use
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-136-
G.k.11 Additional Information on Drug (free text)
User Guidance This data element captures any additional drug information in free text
format not described in G.k.10.r. For example, expiry date for the lot
number described in G.k.4.r.7 would be captured in this data element.
Conformance Optional
Data Type 2000AN
OID None
Value Allowed Free text
Business Rule(s)
If provided, this element needs to be separated and independent from
any value selected in the code list for G.k.10.r.

ICH ICSR Implementation Guide 10 November 2016

-137-
H NARRATIVE CASE SUMMARY AND FURTHER INFORMATION

Sections H.3 and H.5 are repeatable to allow for sufficient space to describe and comment on
the reaction/event and to accommodate for the use of different languages.

H - Narrative Case Summary and Other Information

1…1

H - Narrative Case Summary and Other Information

H.1 - Case Narrative Including Clinical Course, Therapeutic Measures, Outcome and Additional
Relevant Information
H.2 - Reporter’s comments
H.4 - Sender’s comments

H.3.r - Sender’s Diagnosis (repeat as necessary)

H.3.r.1a - MedDRA Version for Sender's Diagnosis / Syndrome and / or

0…n
Reclassification of Reaction / Event
H.3.r.1b - Sender's Diagnosis / Syndrome and / or Reclassification of
Reaction / Event (MedDRA code)

H.5.r - Case Summary and Reporter’s Comments in Native Language

0…n (repeat as necessary)
H.5.r.1a - Case Summary and Reporter’s Comments Text
H.5.r.1b - Case Summary and Reporter’s Comments Language

H.1 Case Narrative Including Clinical Course, Therapeutic Measures, Outcome and
Additional Relevant Information
User Guidance This data element captures a focused, factual and clear description of the
case, including the words or short phrases used by the reporter.
Conformance Required
Data Type 100000AN
OID None
Value Allowed Free text
Business Rule(s)
Each ICSR must include a narrative.
This data element should not be confused with Reporter’s or Sender’s
comments.

ICH ICSR Implementation Guide 10 November 2016

-138-
H.2 Reporter's Comments
User Guidance This data element captures the reporter's comments on the diagnosis,
causality assessment or other issues considered relevant.
Conformance Optional
Data Type 20000AN
OID None
Value Allowed Free text
Business Rule(s)

H.3.r Sender's Diagnosis (repeat as necessary)

H.3.r.1a MedDRA Version for Sender's Diagnosis / Syndrome and / or Reclassification of

Reaction / Event

User Guidance This data element provides the MedDRA version for H.3.r.1b.
Conformance Optional, but required if H.3.r.1b is populated.
Data Type 4AN
OID None
Value Allowed Numeric and ‘.‘(dot)
Business Rule(s)
Only 1 MedDRA version is allowed per ICSR.
For MedDRA version 15.1 value allowed is ‘15.1’.

H.3.r.1b Sender's Diagnosis / Syndrome and / or Reclassification of Reaction / Event

(MedDRA code)

User Guidance This data element provides the sender with an opportunity to combine
signs and symptoms that were reported into a succinct diagnosis.
Supporting rationale for the term selection is included in Section H.4.A
MedDRA LLT code should be used.
Conformance Optional, but required if H.3.r.1a is populated.
Data Type 8N
OID 2.16.840.1.113883.6.163
Value Allowed Numeric
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-139-
H.4 Sender's Comments
User Guidance This data element captures the sender's assessment of the case and can
be used to describe disagreement with, and/or alternatives to the
diagnoses given by the reporter(s).Also, in case of linkage of multiple
ICSRs using C.1.10.r, the reason should be provided in these comments.
Conformance Optional
Data Type 20000AN
OID None
Value Allowed Free text
Business Rule(s)

H.5.r Case Summary and Reporter’s Comments in Native Language (repeat as necessary)
This section provides information on the clinical course of the case, therapeutic measures,
outcome and other relevant information, as well as the reporter’s comments on the case in a
language different from that used in Sections H.1, H.2, and H.4.

H.5.r.1a and H.5.r.1b are used in combination to transmit the sender’s and receiver’s comments
in a language other than English, as required in some countries and regions.

H.5.r.1a Case Summary and Reporter’s Comments Text

User Guidance See Section H.5.r.

Conformance Optional
Data Type 100000AN
OID None
Value Allowed Free text
Business Rule(s)

H.5.r.1b Case Summary and Reporter’s Comments Language

User Guidance Provide the language used in H.5.r.1a by using an International

Standard, Codes for the representation of names of languages-- Part 2:
alpha-3 code.
Conformance Required if H.5.r.1a is populated.
Data Type 3A
OID 2.16.840.1.113883.6.100
Value Allowed ISO 639-2/RA, alpha-3
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-140-
3.5 DOCUMENT ATTACHMENTS

In order to provide supplemental information, the sender of an ICSR might need to attach
documents to the ICSR. Attachments can be presented in-line within the ICSR message itself;
however, a reference to a document URL is not permitted. In-line data is transmitted as part of
the encapsulated data value in the ICSR message.

3.5.1 User Guidance

When the sender holds a clinical document other than a literature article provided from a
primary source (e.g. autopsy reports, ECG strips, chest X-ray, or photographs, etc), then C.1.6.1
should be set to ‘true’ and a description of that document is required in C.1.6.1.r.1. Furthermore,
an electronic file of that document can be attached in C.1.6.1.r.2.

When a literature article is sent as an attachment, the literature citation in Vancouver style is
captured in C.4.r.1 and the electronic file of the document (e.g. journal article) is attached in
C.4.r.2, rather than in C.1.6.1.r.2. (Please refer to Section 3.4 for detailed specifications for
each data element.)

Within one ICSR, multiple document titles (C.1.6.1.r) and literature titles (C.4.r.1) can be
provided, as well as the associated materials. Although several file formats of documents (e.g.
PDF, jpeg, tiff, and DICOM) are technically permissible as attachments, each region will
determine the file types and the file size that can be processed.

When an ICSR contains attachments following the previous report, field ‘Report
Nullification/Amendment’ (C.1.11.1) should be set to ‘2=amendment’ if medical information
captured in E2B(R3) data elements is the same as that of the previous report (see the guidance
for C.1.11.1). Otherwise, the ICSR, along with its attachments, should be transmitted as a
follow-up report.

3.5.2 Technical specification

Embed attachments into the structure of the ICSR XML message. Providing a hyperlink to the
document stored separately is not acceptable.

Each attachment has up to 3 properties, and the appropriate value for each property should be
provided in either C.1.6.1.r.2 or C.4.r.2:
i) Media Type: Identifies the type of the encapsulated data and identifies a method to
interpret or render the data. This property indicates the data type standardised by RFC 2046
(http://www.ietf.org/rfc/rfc2046.txt), (e.g. application/PDF, image/jpeg,
application/DICOM).The default value for media Type is text/plain.
ii) Representation: Presents the type of the encapsulated data. Use TXT for text data or B64
for binary data encoded by Base 64.
iii) Compression: Indicates whether the data is compressed, and what compression algorithm
was used (e.g. value DF means the deflate algorithm was used).

ICH ICSR Implementation Guide 10 November 2016

-141-
3.5.3 Examples of XML instances
When an ICH ICSR message has 2 documents as attachment, one is a PDF file and the other is a
compressed JPEG file, these attachments are encoded in XML instance.

<reference typeCode=”REFR”>
<document classCode=”DOC” moodCode=”EVN”>
<code code=”documentsHeldBySender”
codesystem=”2.16.840.1.113883.3.989.2.1.1.27”/>
<title>C.1.6.1.r.1</title>
<text mediaType='application/pdf' representation='B64'>
omSJUEdmde9j44zmMiromSJUEdmde9j44zmMirdMDSsWdIJdksIJR3373jeu836edjz
MMIjdMDSsWdIJdksIJR3373jeu83MNYD83jmMdomSJUEdmde9j44zmMir..MNYD
83jmMdomSJUEdmde9j44zmMir6edjzMMIjdMDSsWdIJdksIJR3373jeu834zmMir6ed
jzMMIjdMDSsWdIJdksIJR3373jeu83==
</text>
</document>
</reference>
<reference typeCode=”REFR”>
<document classCode=”DOC” moodCode=”EVN”>
<code code=”documentsHeldBySender”
codesystem=”2.16.840.1.113883.3.989.2.1.1.27”/>
<title>C.1.6.1.r.1</title>
<text mediaType='image/jpeg' representation='B64' compression="DF">
omSJUEdmde9j44zmMiromSJUEdmde9j44zmMirdMDSsWdIJdksIJR3373jeu836edjz
MMIjdMDSsWdIJdksIJR3373jeu83MNYD83jmMdomSJUEdmde9j44zmMir..MNYD
83jmMdomSJUEdmde9j44zmMir6edjzMMIjdMDSsWdIJdksIJR3373jeu834zmMir6ed
jzMMIjdMDSsWdIJdksIJR3373jeu83==
</text>
</document>
</reference>

ICH ICSR Implementation Guide 10 November 2016

-142-
4.0 THE ICSR ACKNOWLEDGEMENT TRANSACTION

An acknowledgment transaction will be sent after receipt of every ICH ICSR from known
trading partners (information received from unauthorized or unknown trading partners is not
acknowledged).The acknowledgement message includes a standard ICH ICSR header, an
acknowledgment for the message, and a repeating details section that provides information
about the processing of the original message, e.g. successful parsing or problems that prevented
parsing/accepting the message.

It is important to note that the ICH ICSR Acknowledgement is structured as the response to a
batch message, and that it contains information both for the batch and for individual messages
(reports) within that batch.

4.1 Acknowledgement Message in HL7

Within HL7 messaging, this functionality is managed using the Transmission Infrastructure.

For the purposes of this IG, it will be assumed that all transactions are batched, and that all
responses will refer to the original batch wrapper, as well as to the message. The root message
types needed are MCCI_IN200101UV and MCCI_MT200101UV; the stub is
MCCI_MT000200UV.

For the purposes of this IG, it will be assumed that all transactions are batched, and
that all responses will refer to the original batch wrapper, as well as to each message
in that batch.

4.2 ICH ICSR Acknowledgement Message

The Acknowledgement header contains core transactional information related to the receipt of
the batch transmission. The data elements used for the ICH ICSR Acknowledgement are
described below.

Data elements beginning with ACK.M contain technical information required for
Acknowledgement message.

Data elements beginning with ACK.A contain technical information relating to batch received.
This A section provides information to identify the batch being acknowledged as well as
providing summary data on receipt and parsing. In particular, the information provided is for
the entire batch rather than for any specific ICSR message in that batch.

Data elements beginning with ACK.B contain information relating to each ICSR message
within the received batch. This B section contains information related to each ICSR message
within a batch, including any errors detected within the message.

ICH ICSR Implementation Guide 10 November 2016

-143-
 ACK.M/A - ICH ICSR Batch Acknowledgement Header

1…1

ACK.M/A - ICH ICSR Batch Acknowledgment Header

ACK.M.1 - Acknowledgment Batch Number

ACK.M.2 - Acknowledgment Batch Sender Identifier
ACK.M.3 - Acknowledgment Batch Receiver Identifier
ACK.M.4 - Acknowledgment Date of Batch Transmission

ACK.A.1 - ICSR Batch Number

ACK.A.2 - Acknowledgement　Local message Number
ACK.A.3 - Date of ICSR Batch Transmission
ACK.A.4 - Transmission Acknowledgement Code
ACK.A.5 - Parsing Error Message

ACK.B.r - ICH ICSR Message Acknowledgement Header

ACK.B.r.1 - ICSR Message Number

1…n
ACK.B.r.2 - Local Report Number
ACK.B.r.3 - ICSR Message ACK Receiver
ACK.B.r.4 - ICSR Message ACK Sender
ACK.B.r.5 - Date of ICSR Message Creation
ACK.B.r.6 - Acknowledgment Code for a ICSR Message
ACK.B.r.7 - Error Message or Comment

These header elements are used to organise and identify the acknowledgement transaction. The
ACK header elements relate to the Message Header elements in received ICSR messages. The
diagram below illustrates the submission and acknowledgement transaction at the batch
message level.

ICH ICSR Implementation Guide 10 November 2016

-144-
 ICSR Batch
M.1.4
Batch Sender Batch Receiver
N.1.3 N.1.4

Validation

ACK Batch ACK Batch

Receiver Sender
ACK.M.3 ACK.M.2

ICSR ACK
ACK.M.1

Organisation that is Organisation that is

submitting the ICH receiving the ICH
ICSR ICSR

ACK.M / AICH ICSR BATCH ACKNOWLEDGEMENT

ACK.M.1 Acknowledgement Batch Number

User Guidance This data element captures a unique tracking number assigned to a
particular ICH ICSR Acknowledgement batch file transmitted by the
sender. This number is unique to the sender.
Conformance Required
Data Type 100AN
OID None
Value Allowed Free text
Business Rule(s)

ACK.M.2 Acknowledgement Batch Sender Identifier

User Guidance This data element identifies the sender of the ICH ICSR
Acknowledgement batch file (creator of ICH ICSR Acknowledgement
batch file).
Conformance Required
Data Type 60AN
OID 2.16.840.1.113883.3.989.2.1.3.17
Value Allowed Free text
Business Rule(s)
This should be the same identifier as N.1.4.

The following notation will be used to represent ACK.M.2:

ICH ICSR Implementation Guide 10 November 2016

-145-
 <id extension="acknowledgement sender
identifier"root="2.16.840.1.113883.3.989.2.1.3.17"/>

The root indicates the namespace of ACK.M.2, the actual batch sender
identifier is populated at id extension. The sender identifier should be
agreed between trading partners.

ACK.M.3 Acknowledgement Batch Receiver Identifier

User Guidance This data element identifies the intended recipient of the transmission of
ICH ICSR Acknowledgement batch file.
Conformance Required
Data Type 60AN
OID 2.16.840.1.113883.3.989.2.1.3.18
Value Allowed Free text
Business Rule(s)
This should be the same identifier as N.1.3.

The following notation will be used to represent ACK.M.3:

<id extension="acknowledgement receiver identifier"
root="2.16.840.1.113883.3.989.2.1.3.18"/>

The root indicates the namespace of ACK.M.3, the actual batch receiver
identifier is populated at id extension. The sender identifier should be
agreed between trading partners.

ACK.M.4 Acknowledgement Date of Batch Transmission

User Guidance This data element captures the date on which the ICH ICSR
Acknowledgement batch file was transmitted.
Conformance Required
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
Business Rule(s)
Minimum precision required is date and time to the second.
The date specified cannot refer to a future date; the time zone may have to
be specified.
(i.e. ‘CCYYMMDDhhmmss[+/-ZZzz]’)

ICH ICSR Implementation Guide 10 November 2016

-146-
ACK.A.1 ICSR Batch Number
User Guidance This data element identifies the transaction (that is the batch) that is being
acknowledged. It is a unique tracking number that was assigned to the
ICH ICSR batch file by its sender. This ICSR batch number is unique to
the sender of the ICH ICSR batch (i.e. the organisation that submitted the
ICH ICSR).
Conformance Required
Data Type 100AN

OID None
Value Allowed Free text
Business Rule(s)
This should be the same number as N.1.2 of the batch being
acknowledged.

ACK.A.2 Acknowledgement Local Message Number

User Guidance This data element captures a value assigned to the ICH ICSR Batch
Acknowledgement by the organisation sending the acknowledgement (i.e.
the organisation that received the ICH ICSR).
Conformance Optional
Data Type 100AN
OID None
Value Allowed Free text
Business Rule(s)

ACK.A.3 Date of ICSR Batch Transmission

User Guidance This data element captures the date on which the ICSR batch being
acknowledged was originally sent.
Conformance Required
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information
Business Rule(s)
This should be the same date as N.1.5.

ICH ICSR Implementation Guide 10 November 2016

-147-
ACK.A.4 Transmission Acknowledgement Code
User Guidance This data element captures a code to inform the organisation that
submitted the ICH ICSR batch whether to (i) take no further action, (ii)
review the remainder of the acknowledgement to determine which ICSR
message(s) need further action, or (iii) re-send the entire transaction .
Conformance Required
Data Type 2A
OID None
Value Allowed AA – Application Acknowledgement Accept (message successfully
processed, no further action)
AE – Application Acknowledgment Error (error detected, error response
has additional detail, some ICSR message(s) need further action)
AR – Application Acknowledgment Reject (parsing error, no data
extracted, re-send the entire transaction)
Business Rule(s)

ACK.A.5 Batch Validation Error

User Guidance This data element provides a description of the error(s)detected in the ICH
ICSR batch XML. This data element contains an explanation for the code
triggered in ACK.A.4.
Conformance Optional
Data Type 250AN
OID None
Value Allowed Free text
Business Rule(s)

ACK.B ICH ICSR MESSAGE ACKNOWLEDGEMENT

ACK.B.r.1 ICSR Message Number

User Guidance This data element captures the number assigned to each ICH ICSR
message (each message within a batch)by the organisation that submitted
the ICH ICSR.
Conformance Required
Data Type 100AN
OID None
Value Allowed Free text
Business Rule(s)
This is the same as N.2.r.1 and C.1.1 (Sender’s (case) Safety Report
Unique Identifier).

ACK.B.r.2 Local Report Number

User Guidance This data element captures the number assigned to the ICH ICSR message
by the organisation that received the ICH ICSR.
Conformance Optional
Data Type 100AN
OID None

ICH ICSR Implementation Guide 10 November 2016

-148-
 Value Allowed Free text
Business Rule(s)

ACK.B.r.3 ICSR Message ACK Receiver

User Guidance This data element identifies the organisation that submitted the ICH ICSR
message (creator of ICH ICSR message).
Conformance Required
Data Type 60AN
OID 2.16.840.1.113883.3.989.2.1.3.16
Value Allowed Free text
Business Rule(s)
This should be the same identifier as N.2.r.2.

The following notation will be used to represent ACK.B.r.3:

<id extension="ack receiver identifier"
root="2.16.840.1.113883.3.989.2.1.3.16"/>

The root indicates the namespace of ACK.B.r.3, the actual message

receiver identifier is populated at id extension. The ACK receiver
identifier should be agreed between trading partners.

ACK.B.r.4 ICSR Message ACK Sender

User Guidance This data element identifies the organisation that received the ICH ICSR
message.
Conformance Required
Data Type 60AN
OID 2.16.840.1.113883.3.989.2.1.3.15
Value Allowed Free text
Business Rule(s)
This should be the same identifier as N.2.r.3.

The following notation will be used to represent ACK.B.r.4:

<id extension="ack sender identifier"
root="2.16.840.1.113883.3.989.2.1.3.15"/>

The root indicates the namespace of ACK.B.r.4, the actual message sender
identifier is populated at id extension. The ACK sender identifier should
be agreed between trading partners.

ACK.B.r.5 Date of ICSR Message Creation

User Guidance This data element captures the date the ICSR message was created.
Conformance Required
Data Type Date / Time
OID None
Value Allowed See Appendix II for further information.
Business Rule(s)
This should be the same as N.2.r.4 and C.1.2 (Date of Creation).

ICH ICSR Implementation Guide 10 November 2016

-149-
ACK.B.r.6 Acknowledgement Code for a ICSR Message
User Guidance This data element captures a code to inform the organisation that
submitted the ICH ICSR message whether to (i) ICSR message
successfully loaded, or (ii) the ICSR message contains fatal error that
prevents the ICSR from being loaded.
Conformance Required
Data Type 2A
OID None
Value Allowed CA – Commit Accept (the ICSR message successfully loaded)
CR – Commit Reject(the ICSR message contains fatal error that prevents
the ICSR from being loaded)
Business Rule(s)

ACK.B.r.7 Error / Warning Message or Comment

User Guidance This data element provides a description of the error(s) detected in the
ICH ICSR message. This data element contains an explanation for the
code triggered in ACK.B.r.6, including non-fatal warning messages when
ACK.B.r.6 is ‘CA’.
Conformance Optional
Data Type 250AN
OID None
Value Allowed Free text
Business Rule(s)

ICH ICSR Implementation Guide 10 November 2016

-150-
APPENDICES

The following appendices contain specifications related to various components referenced

throughout this document. These appendices provide the necessary details to facilitate the
preparation of a valid ICH ICSR message or an ICSR Acknowledgment message for electronic
submission.

APPENDIX I – PREPARING AND SENDING ICH ICSRS:

Appendix I (A) – ICH ICSR SCHEMAs

1. List of schemas for ICH ICSR messages and ICSR Acknowledgement messages

The necessary schemas for creating or exchanging ICH ICSR messages and ICH
Acknowledgement messages are listed as schema file names which can be identified from
Appendix I (C) schema files. These schemas are included in a published standard package
named ISO/HL7 27953-2 (published on 21 November 2011). HL7 has developed each schema
as an individual file, and used XML ‘include’ statements to link these files. All schema files
with user guidance are listed by categorisation.

Major Category Sub-Category Schema File Name

a. Core Schemas: - infrastructureRoot
A common schemas datatypes-base
underlying HL7 datatypes
messages voc
b. Send Batch ICSR Batch Interaction: MCCI_IN200100UV01
Interaction: Batch wrapper schemas for single or MCCI_MT200100UV
A schema set specific to multiple ICSR messages
ICSR messages ICSR Single Interaction: PORR_IN049016UV
Schemas for individual ICSR MCCI_MT000100UV01
message MCAI_MT700201UV01
PORR_MT049016UV
PORR_MT049023UV
ICSR Common Product Model POCP_MT010200UV
CMET: POCP_MT020200
Schemas for medicinal products POCP_MT030100UV
POCP_MT030200UV
POCP_MT040100UV
POCP_MT050100UV
POCP_MT081100UV
c. Send Response Batch Acknowledgement Batch MCCI_IN200101UV01
Interaction: Interaction: MCCI_MT200101UV
A schema set for Batch wrapper schemas for
Acknowledgement Acknowledgement messages
messages
Acknowledgement Single MCCI_IN000002UV01
Interaction: MCCI_MT000200UV01

ICH ICSR Implementation Guide 10 November 2016

-151-
 Schemas for each Acknowledgement
message

2. User Guidance for each ICH ICSR schemas

a. Core Schemas

infrastructureRoot

User Infrastructure Root Class locates at the top layer of HL7 Class structure and
Guidance defines necessary properties which are applied to all elements in messages for
transmission.
This schema, derived from Infrastructure Root Class, defines attributes
commonly used in complex type where attributes or child elements are
defined. infrastructureRoot schema is referenced from complex type.

datatypes-base

User The HL7 datatypes, which are used within the definition of all model
Guidance elements, are defined within the two schemas, datatypes-base, and datatypes.
Datatypes-base schema defines data types for both complex type (e.g. ED,
CD) and simple type (e.g. ST, CS).
HL7 data types are categorised into ‘Basic data type’ and ‘Generic data type’.
This schema defines Basic data type and part of Generic data type. Basic data
type is a combination of Generic data types and such components are included
in this schema.

datatypes

User The HL7 datatypes, which are used within the definition of all model
Guidance elements, are defined within the two schemas, datatypes-base and datatypes.
Datatypes defines ‘Generic data type’ which is used by setting a parameter in
definition (e.g. A Generic data type IVL_<T> becomes IVL_<TS> or
IVL_<PQ> with parameters at <T>).

voc

User The schema includes the vocabulary items that are defined by HL7 for use by
Guidance all Implementers (at the ‘universal’ level).It includes the vocabulary domains
that have been defined through RIM harmonisation, and the value sets that are
defined by HL7.For the most part, these apply to HL7 structural attributes,
and to data types.

Note: Only NarrativeBlock schema in core schema set is not used for ICH ICSR messages and
ICSR Acknowledgement message.

ICH ICSR Implementation Guide 10 November 2016

-152-
b. Send Batch Interaction

ICSR Batch Interaction

MCCI_IN200100UV01

User ‘Sends a Batch, which groups 0 or more Messages for communication

Guidance purposes’ (ISO/HL7 27953-2).
For ICH ICSR messages, this schema defines root element.

MCCI_ MT200100UV

User ‘The Batch class functions in similar way to the Message class in an
Guidance individual V3 message’ (ISO/HL7 27953-2).

For ICH ICSR messages, this schema defines all of data elements in N.1
section.

ICSR Single Interaction

PORR_IN049016UV

User This schema is corresponding to individual ICSR messages in a Batch

Guidance message.

For ICH ICSR messages, this schema defines individual reports including
initial, follow-up and nullification in a batch message, while HL7 provides
separated schemas for each report.

MCCI_MT000100UV01

User ‘The “HL7 Transmission wrapper” includes information needed by a sending

Guidance application or message handling service to package and route the V3
Composite Message to the designated receiving application(s) and/or message
handling service(s)’ (ISO/HL7 27953-2).

For ICSR messages, this schema defines most of data elements in N.2 section.

MCAI_MT700201UV01

User ‘The “Trigger Event Control Act” contains administrative information related
Guidance to the "controlled act" which is being communicated as a messaging
interaction’(ISO/HL7 27953-2).

It specifies the intermediate wrapper structure in the HL7 version 3 composite

message payload specification that is used for notification and request for
action type message interactions.
For ICH ICSR messages, this schema defines the Date of Creation (C.1.2).

ICH ICSR Implementation Guide 10 November 2016

-153-
PORR_MT049016UV

User ‘The Human Pharmaceuticals Base Model RMIM is designed to support a

Guidance report about an investigation into an adverse event(s) or reaction(s) suffered
by a person that experienced an intervention (substance administration or
procedure) within a therapeutic context. The suspect event may or may not
have a causal relationship with the intervention and the model supports events
suffered by associated persons e.g. mother/child or siblings‘ (ISO/HL7 27953-
2).

PORR_MT049023UV

User ‘The A_HumanPharmaceuticalsPRRI RMIM captures information about the

Guidance acts that describe how a product was used by an investigative subject. The
information includes use of a product (substance administration and device
procedures) and any associated clinical or laboratory information directly
related to the product's use at a particular point in time, e.g. related to an
adverse event, or as part of a subject's medical history. The model also
supports other patient care or healthcare-related processes such as actions
taken to mitigate or reduce harm’ (ISO/HL7 27953-2).

ICSR Common Product Model CMET

POCP_MT010200UV

User This schema is derived from ‘E_ProductKind CMET’ which supports

Guidance specified drug information.

For ICH ICSR messages, this schema defines drug information such as
identifiers (e.g. Medicinal Product Identifier (MPID) (G.k.2.1.1b) and
Pharmaceutical Product Identifier (PhPID) (G.k.2.1.2b)) and the
Pharmaceutical Dose Form (G.k.4.r.9).

POCP_MT020200UV

User This schema is derived from ‘R_ProductReportable CMET’ which supports

Guidance information of drugs in reports and drugs for administration.

For ICH ICSR messages, this schema defines the Batch / Lot Number
(G.k.4.r.7).

POCP_MT030100UV

User This schema is derived from ‘R_ProductRelatedAssignedEntity CMET’:

Guidance ‘A combination of a person and/or organisation involved in the product life
cycle in some way (e.g. creation and review of a product labeling document,
performing a testing activity)‘ (ISO/HL7 27953-2).

For ICH ICSR messages, this schema defines the Identification of the Country
Where the Drug Was Obtained (G.k.2.4).

ICH ICSR Implementation Guide 10 November 2016

-154-
POCP_MT030200UV

User This schema is derived from ‘E_ProductEstablishment CMET’:

Guidance ‘Any organisation that plays a role in the product life-cycle in any
way‘ (ISO/HL7 27953-2).

For ICH ICSR messages, this schema defines the Name of Holder / Applicant
(G.k.3.3).

POCP_MT040100UV

User This schema is derived from ‘A_ProductEvent CMET’ which supports

Guidance information on drug manufacturing, transportation, and control with
referencing to ‘R_ProductRelatedAssigned Entity CMET’.

For ICH ICSR messages, the Identification of the Country Where the Drug
Was Obtained (G.k.2.4) is mapped to R_ProductRelatedAssigned Entity
CMET and thus defined by this schema.

POCP_MT050100UV

User This schema is derived from ‘A_ProductInformation CMET’ which supports

Guidance information on approval of new drug marketing and relevant documents.

For ICH ICSR messages, this schema defines Authorisation / Application

Number (G.k.3.1).

POCP_MT081100UV

User This schema is derived from ‘E_SubstanceClinical CMET’ which supports

Guidance drug ingredients.

For ICH ICSR messages, this schema defines the Substance / Specified
Substance Identifier and Strength (G.k.2.3.r).

c. Send Response Batch Interaction

Acknowledgement Batch Interaction

MCCI_IN200101UV01
User ‘Send a Batch, which groups 0 or more Application level Messages into a
Guidance Batch for communication purposes; sent as a response to either a Batch, or as
a response to a Message which explicitly requested a Batched
response’(ISO/HL7 27953-2).

For Acknowledgement messages, this schema defines root element. The

acknowledgement specialises that of the Transmission by adding structures to
identify the message being acknowledged, and to allow details about the
acknowledgement to be added. This is especially important for reject
messages.

ICH ICSR Implementation Guide 10 November 2016

-155-
MCCI_MT200101UV

User
A Response Batch can be used for (1) batches of accept acknowledgements,
Guidance
(2) batches of application responses. The only difference between this R-
MIM (MCCI_RM200101UV) and the Batch R-MIM (MCCI_RM200100UV)
for ICSR messages is the fact that the former contains a mandatory
Acknowledgement class.

For Acknowledgement messages, this schema defines ACK.M and ACK.A

sections.

Acknowledgement Single Interaction

MCCI_IN000002UV01
User ‘Accept Acknowledgement by Sender to the Receiver. This message would not
Guidance contain a domain payload ‘(ISO/HL7 27953-2).
For Acknowledgement messages, this schema defines ACK.B section.

MCCI_MT000200UV01

User ‘Accept Acknowledgement by Sender to the Receiver. This message would not
Guidance contain a domain payload ‘(ISO/HL7 27953-2).
For Acknowledgement messages, this schema defines ACK.B section.

Appendix I (B) – Backwards & Forwards Compatibility

The document of Backwards & Forwards Compatibility is provided separately from this IG.

Appendix I (C) – Schema files

The set of schema files included in the published standard named ISO/HL7 27953-2 is provided
separately from this IG.

Appendix I (D) – Reference Instances for ICH ICSR message and ICSR
Acknowledgement message
XML files of Reference Instances for both the ICH ICSR and ICSR Acknowledgements
messages are provided separately from this IG.

Appendix I (E) – Example Instances of report cases

XML files of Example Instances are provided separately from this IG.

ICH ICSR Implementation Guide 10 November 2016

-156-
Appendix I (F) – ICH E2B code lists
Lists of ICH E2B codes in XML format are provided separately from this IG.

Appendix I (G) – Technical Information

The document of Technical Information is provided separately from this IG.

Appendix I (H) – SGML & XML conversion

The conversion style sheet is informative materials and provided separately from this IG.

ICH ICSR Implementation Guide 10 November 2016

-157-
APPENDIX II – DATE / TIME

ICH has elected to utilise the HL7 Standard for datatypes to specify numeric representations of
date and time. The time notation is the de facto standard in almost all countries while the date
notation is increasingly popular.HL7 Standard for datatypes notation is the commonly
recommended format for representing date and time as human-readable strings in
communication protocols and file formats.

This notation has several important advantages when used in electronic files or messages as
compared to traditional date and time notations. Since it orders the units from most significant
to least significant, there are benefits with regard to flexibility, sorting, and for comparison after
truncation.

Appendix II (A) Date / Time

The international standard date / time notation is CCYYMMDDhhmmsswhere
i) CCYY is the century and year in the usual Gregorian calendar,
ii) MM is the month of the year between 01 (January) and 12 (December),
iii) DD is the day of the month between 01 and 31,
iv) hh is the number of complete hours that have passed since midnight (00-24),
v) mm is the number of complete minutes that have passed since the start of the hour (00-
59), and
vi) ss is the number of complete seconds since the start of the minute (00-59).

For example, the fourth day of February, 1995 is written as 19950204.

If only the month is of interest, then CCYYMM can be used.

Example: 199502

If only the year is of interest, then just CCYY is acceptable.

Example: 1995

The time (hhmmss) one second before midnight is written as 235959.

The precision can be reduced by omitting the seconds or both the seconds and minutes.

Example: 2359, or just 23

It is also possible to add fractions of a second after a decimal dot (.).

Example: 235959.9942 is 5.8ms before midnight.

ICH ICSR Implementation Guide 10 November 2016

-158-
As every day both ‘start’ and ‘end’ with midnight, the two notations 00:00 and 24:00 are
available. This means that the following two notations refer to exactly the same point in time:

199502042400=199502050000.‘0000’ is usually the preferred notation for midnight and not

‘2400’.

If a date and a time are displayed on the same line, then always write the date in front of the
time.

Example: 19951231235959 is December 31, 1995 at 1 second before midnight.

Appendix II (B) Time Zone

The syntax is ‘CCYYMMDDHHMMSS.UUUU[+|-ZZzz]’ where digits can be omitted from the
right side to express less precision.

Note: The Z stands for the ‘zero meridian’, which goes through Greenwich in London.
Coordinated Universal Time (UTC) was called Greenwich Mean Time (GMT, also known as
‘Zulu Time’) prior to 1972; however, GMT should no longer be used.

The strings +ZZzz, or +ZZ can be added to the time to indicate that the used local time zone is
ZZ hours and zz minutes ahead of UTC. For time zones west of the zero meridian, which are
behind UTC, the notation –ZZzz, or –zz is used instead.

When transmitting across the time zone, use this indicator to ensure no confusion about future
dates.

Example: 200509211242-08 is 12:42 pm (in the time zone that is 8 hours before UTC) on
September 21, 2005.

Appendix II (C) ISO 8601 Compliant XML Examples

April 7, 2000
<effectiveTime value="20000407"/>

12:42 pm (in a time zone 8 hours before UTC) on September 21, 2005.
<effectiveTime value="200509211242-08"/>

Sometime in the year 2000

<effectiveTime value="2000"/>

November 5, 1994, 8:15:30 am, US Eastern Standard Time:

19941105081530-0500 (local time with offset)

ICH ICSR Implementation Guide 10 November 2016

-159-
 To further illustrate date and time: June 1, 2009, at 3:31:15:05:5 pm Pacific Time Zone:
• to the millisecond: 200906011531105.5-0800
• to the second: 20090601231105
• to the minute: 200906012331
• to the hour: 2009060123
• to the day: 20090601
• to the month: 200906
• to the year: 2009

APPENDIX III - ABBREVIATIONS AND GLOSSARY OF TERMS

Appendix III (A) ABBREVIATIONS

Abbreviations Definition
A Alpha
ADR Adverse Drug Reaction
AE Adverse Event
AN Alphanumeric
APEC Asia-Pacific Economic Cooperation
CDISC Clinical Data Interchange Standards Consortium
CE Coded with Equivalents*
CEN Comité Européen de Normalisation (European Committee for Standardisation , a
federation of 28 national standards bodies that are also ISO member bodies)
CIOMS Council for International Organisations of Medical Sciences
CMET Common Message Element Type
CS Coded Simple Value
DSTU Draft Standard for Trial Use
DTD Document Type Definition
ECG Electrocardiogram
ED Encapsulated Data*
EDI Electronic Data Interchange
EDIFACT Electronic Data Interchange for Administration, Commerce and Transport
EEA European Economic Area
EMA European Medicines Agency
EFPIA European Federation of Pharmaceutical Industries and Associations
EFTA European Free Trade Association
ESTRI Electronic Standards for the Transmission of Regulatory Information
EU European Union
FDA United States Food and Drug Administration
HL7 Health Level 7
HMD Hierarchical Message Description
ICH International Conference of Harmonisation
ICSR Individual Case Safety Report
IDMP Identifier for Medicinal Products – inclusive of all controlled vocabularies (See
Section 3.2.1.1)

ICH ICSR Implementation Guide 10 November 2016

-160-
 Abbreviations Definition
IFPMA International Federation of Pharmaceutical Manufacturers Associations
ISO International Organisation for Standardisation
ISO 27953 Reference number for working document prepared by ISO Technical Committee
TC215 on Health informatics jointly with HL7 and CEN.
JIC Joint Initiative Council
JPMA Japan Pharmaceutical Manufacturers Association
LLT Lower Level Term
MAH Market Authorisation Holders
MedDRA Medical Dictionary for Regulatory Activities
MHLW Japan Ministry of Health and Welfare
MPID Medicinal Product Identifier
MSSO Maintenance and Support Services Organization
N Numeric
OID Object Identifier
PANDRH Pan American Network on Drug Regulatory Harmonization
PhPID Pharmaceutical Product Identifier
PhRMA Pharmaceutical Research and Manufacturers of America
PMDA Japan Pharmaceuticals and Medical Devices Agency
RHI Regional Harmonisation initiatives
RIM Reference Information Model
RMIM Refined Message Information Model
RQ Ratio Quantity
SADC South African Development Community
SDO Standards Development Organisation
SGML Standard Generalised Markup Language. An ISO standard for describing
structured information in a platform independent manner
ST Character String*
TS Point in Time*
UCUM UCUM (Unified Code for Units of Measure)
UTC Coordinated Universal Time
W3C World Wide Web Consortium
WHO World Health Organisation
XML eXtensibleMarkup Language
* These acronyms and definitions pertain to HL7.

ICH ICSR Implementation Guide 10 November 2016

-161-
Appendix III (B) GLOSSARY of TERMS

This section identifies the vocabulary sets referenced within the message, including both those
vocabularies already defined and those which are still under development.

In addition, there are many different terms used to describe basic concepts in healthcare
available from various national and international organisations. For the purposes of this
document, the following terms and definitions apply to facilitate conformance and
interoperability for regulatory reporting of adverse events for human pharmaceuticals.

Term Definition
Adverse Event Any untoward medical occurrence in a patient or clinical
investigation subject administered a pharmaceutical product and
which does not necessarily have a causal relationship with this
treatment. An adverse event (AE) can therefore be any
unfavourable and unintended sign (including an abnormal
laboratory finding), symptom, or disease temporally associated
with the use of a medicinal (investigational) product, whether or
not related to the medicinal (investigational) product (see the
ICH Guideline for Clinical Safety Data Management: Definitions
and Standards for Expedited Reporting).[ICHE6(R1)]
Acknowledgement The acknowledgement message is an EDI Message with the
Message (ICSRACK) information on the result of the acknowledgement of receipt
procedure to acknowledge the receipt of one safety message and
the safety report(s) contained in the safety file.[EMA]
Adverse Drug Reaction In the pre-approval clinical experience with a new medicinal
(ADR) product or its new usages, particularly as the therapeutic dose(s)
cannot be established: all noxious and unintended responses to a
medicinal product related to any dose should be considered
adverse drug reactions. The phrase ‘responses to a medicinal
product’ means that a causal relationship between a medicinal
product and an adverse event is at least a reasonable possibility,
e.g. the relationship cannot be ruled out.
Regarding marketed medicinal products: a response to a drug
which is noxious and unintended and which occurs at doses
normally used in man for prophylaxis, diagnosis, or therapy of
diseases or for modification of physiological function (See the
ICH Guideline for Clinical Safety Data Management: Definitions
and Standards for Expedited Reporting).[ICHE6(R1)]
Case An observation requiring investigation, and includes problems
that might or might not involve individual or groups of
investigative subjects.[HL7 Patient Safety]

ICH ICSR Implementation Guide 10 November 2016

-162-
Term Definition
Counterfeit Medicine A medicine which is deliberately and fraudulently mislabelled
with respect to identity and/or source. Counterfeiting can apply
to both branded and generic products and counterfeit products
can include products with the correct ingredients or with the
wrong ingredients, without active ingredients, with insufficient
active ingredients or with fake packaging.[WHO] 13
Drug (See Medicinal Product)
Electronic Data Interchange A technology for exchanging structured information for the
(EDI) purpose of conducting business transactions.[ICH M2]
EDI Message An EDI Message consists of a set of segments, structured using
an agreed standard, prepared in a computer readable format and
capable of being automatically and unambiguously
processed.[EMA]
Healthcare Professional Person entrusted with the direct or indirect provision of defined
healthcare services to a subject of care or a population of
subjects of care[ENV 1613:1995] [ISO 21574-7]
EXAMPLE Qualified medical practitioner, pharmacist, nurse,
social worker, radiographer, medical secretary or clerk
Individual Case Safety The complete information provided by a reporter at a certain
Report point in time to describe an event or incident of interest. The
report can include information about a case involving one subject
or a group of subjects. [27953 Human Pharmaceutical
Reporting]
Marketing Authorisation An organisation, usually a biopharmaceutical firm, that holds a
Holder valid marketing authorisation for a medicinal product delivered
by the Health Authority of a country.
Medical Dictionary for Medical Dictionary for Regulatory Activities (MedDRA)
Regulatory Activities terminology for adverse event reporting used globally by the
biopharmaceutical industry and regulators to promote consistent
reporting and data analysis.
Medicinal Product Any substance or combination of substances presented as having
properties for treating or preventing disease in human beings;

Any substance or combination of substances which might be

used in or administered to human beings either with a view to
restoring, correcting or modifying physiological functions by
exerting a pharmacological, immunological or metabolic action,
or to making a medical diagnosis.[ISO 11615]

Any substance or combination of substances which might be

administered to human beings or animals for treating or
preventing disease, with the view to making medical diagnosis or
to restore, correct or modify physiological functions [ENV
13607] [Directive 65/65/EEC, modified]

13WorldHealth Organisation International Medical Products Anti-Counterfeiting Task Force

(IMPACT)http://www.who.int/impact/FinalBrochureWHA2008a.pdf

ICH ICSR Implementation Guide 10 November 2016

-163-
Term Definition
Non-proprietary Drug Drug name that is not protected by a trademark, usually
(generic) Name descriptive of its chemical structure; sometimes called a public
name. International Non-proprietary Names (INN) allocated by
WHO, identify pharmaceutical substances or active
pharmaceutical ingredients. Each INN is a unique name that is
globally recognised and is public property. A non-proprietary
name is also known as a generic name. In the US, most generic
drug names are assigned by the US Adopted Name Council
(USAN).
Pharmacovigilance The science of activities relating to the detection, assessment,
understanding and prevention of adverse effects or any other
drug-related problem.[(2) WHO; 2002;]
Product A thing or things produced by labour or effort for a specific use
and marketed to satisfy a need or want. [HL7 Patient Safety]
Regional A governmentally recognised centre (or integrated system)
Pharmacovigilance Centre within a country with the clinical and scientific expertise to
collect, collate, analyze and give advice on all information
related to drug safety.
Regulatory Agency or Geopolitical entities have established agencies/authorities
Regulatory Authorities responsible for regulating products used in health care. The
agencies are collectively referred to as regulatory agencies.
Reference Information The HL7 information model from which all other information
Model (RIM) models, e.g. RMIMS, and messages are derived.
Refined Message An information structure that represents the requirements for a
Information Model set of messages.
(RMIM)
Reporter The primary source of the information, e.g. a person who
initially reports the facts provided in the ICSR. This should be
distinguished from the sender of the message, though the
reporter could also be a sender.[ICH E2B(R2)]
Safety Message A safety message is an EDI message including the information
provided for one/more Individual Case Safety Reports contained
in one safety file exchanged between one sender and one
receiver in one message transaction.[EMA]
Sender The person or entity creating the message for transmission.
Although the reporter and sender may be the same person, the
function of the sender should not be confused with that of the
reporter.[ICH E2B(R2)]
Serious Adverse Reaction Any untoward medical occurrence that at any dose:
or Serious Adverse Drug - results in death,
Reaction - is life-threatening,
- requires inpatient hospitalization or prolongation of existing
hospitalization,
- results in persistent or significant disability/incapacity,
or
- is a congenital anomaly/birth defect
(see the ICH Guideline for Clinical Safety Data Management:
Definitions and Standards for Expedited Reporting).[ICH
E6(R1)]

ICH ICSR Implementation Guide 10 November 2016

-164-
Term Definition
Sponsor An individual, company, institution, or organization which takes
responsibility for the initiation, management, and/or financing of
a clinical trial. [ICH E6(R1) & E2F]
Spontaneous Reporting An unsolicited communication to a company, regulatory
authority or other organisation that describes an adverse drug
reaction in a patient given one or more medicinal products and
which does not derive from a study or any organized data
collection scheme.[ICH E2C(R1)]
Standard A technical specification which addresses a business
requirement, has been implemented in viable commercial
products, and, to the extent practical, complies with recognised
standards organisations such as ISO.
Use Case A description of a system's behaviour as it responds to a request
that originates from outside of that system.[Objectory AB]

ICH ICSR Implementation Guide 10 November 2016

-165-