Guidance for Industry 
 
E2B(R3) Electronic Transmission of 
Individual Case Safety Reports (ICSRs)  
Implementation Guide   
Data Elements and Message 
Specification 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
U. S. Department of Health and Human Services 
Food and Drug Administration 
Center for Drug Evaluation and Research (CDER) 
Center for Biologics Evaluation and Research (CBER) 
 
April 2022 
ICH 
 
Revision 1
 
       
Guidance for Industry 
 
E2B(R3) Electronic Transmission of 
Individual Case Safety Reports (ICSRs)  
Implementation Guide   
Data Elements and Message Specification 
 
Additional copies are available from: 
Office of Communications, Division of Drug Information  
Center for Drug Evaluation and Research 
Food and Drug Administration 
10001 New Hampshire Ave., Hillandale Bldg., 4th Floor  
Silver Spring, MD 20993-0002  
Phone: 855-543-3784 or 301-796-3400; Fax: 301-431-6353 
Email: druginfo@fda.hhs.gov  
https://www.fda.gov/drugs/guidance-compliance-regulatory-information/guidances-drugs 
and/or 
Office of Communication, Outreach and Development  
Center for Biologics Evaluation and Research 
 Food and Drug Administration 
10903 New Hampshire Ave., Bldg. 71, Room 3128 
Silver Spring, MD 20993-0002 
Phone: 800-835-4709 or 240-402-8010 
Email: ocod@fda.hhs.gov 
https://www.fda.gov/vaccines-blood-biologics/guidance-compliance-regulatory-information-biologics/biologics-guidances     
   
 
 
 
U.S. Department of Health and Human Services 
Food and Drug Administration 
Center for Drug Evaluation and Research (CDER) 
Center for Biologics Evaluation and Research (CBER) 
 
April 2022 
ICH 
 
Revision 1
 
      Contains Nonbinding Recommendations 
 
 
 
This guidance represents the current thinking of the Food and Drug Administration (FDA or Agency) 
on this topic.  It does not establish any rights for any person and is not binding on FDA or the public.  
You can use an alternative approach if it satisfies the requirements of the applicable statutes and 
regulations.  To discuss an alternative approach, contact the FDA office responsible for this guidance 
as listed on the title page.   
 
 
 
Note 1:  This guidance was jointly developed by the E2B(R3) and M2 Expert Working 
Groups of the International Council for Harmonisation of Technical Requirements for 
Pharmaceuticals for Human Use (ICH) and has been subject to consultation by the regulatory 
parties, in accordance with the ICH process.  This document has been endorsed by the ICH 
Steering Committee at Step 4 of the ICH process, November 2012.  At Step 4 of the process, 
the final draft is recommended for adoption to the regulatory bodies of the European Union, 
Japan, and the United States. 
 
Note 2:  FDA has added title pages and front matter to meet the requirements of the 
Agencys good guidance practices.  FDA has maintained all other elements of the original 
implementation guidance, including pagination and heading numbers.  The heading numbers 
are consistent with the structure and format of the ICH E2B(R3) Implementation Guide. * 
 
 
 
 
 
 
A technical specifications document associated with this guidance will be provided as a 
stand-alone document, FDA Regional Implementation Guide for E2B(R3) Electronic 
Transmission of Individual Case Safety Reports for Drug and Biological Products.  To 
ensure that you have the most recent version of the technical specifications document, 
check the guidance Web page at  
http://www.fda.gov/Drugs/GuidanceComplianceRegulatoryInformation/Guidances/defa
ult.htm.
 
* This guidance was updated to incorporate technical updates made to the ICH Individual Case Safety 
Report Implementation Guide in 2016.  You may submit comments on this guidance at any time.  
Submit comments to Docket No. FDA-2011-D-0720 (available at 
https://www.regulations.gov/search?filter=FDA-2011-D-0720). 
 
     
  Contains Nonbinding Recommendations 
 
 
Document History 
 
Date of  Title of Document  Version  Published for  EWG 
Finalisation 
February  Maintenance of The ICH Guideline on  4.4.1  Step 4  E2B 
Clinical Safety Data Management : Data 
2001  document 
Elements For Transmission of Individual 
Case Safety Reports  E2B(M)* 
*Renamed E2B(R2) in 2005 
Electronic Transmission of Individual Case  2.3  M2 
Safety Reports Message Specification (ICH 
ICSR DTD v2.1) 
May 2005  Revision of The ICH Guideline on Clinical  2.0  First Public  E2B 
Safety Data Management: Data Elements for 
Consultation 
Transmission of 
Individual Case Safety ReportsE2B(R) 
 June 2009  Electronic Transmission of Individual Case  1.31  First Step 2 for  M2 / 
Safety Reports Message Specification  
Testing  E2B 
Implementation Guide  
(ICH ICSR Message Version 3.96) 
April 2010  Electronic Transmission of Individual Case  2.47  Second Step 2  M2 / 
Safety Reports Implementation Guide 
for Testing  E2B 
Data Elements and Message Specification 
June 2011  Electronic Transmission of Individual Case  3.01  Second Public  E2B 
Safety Reports (ICSRs) 
Consultation 
Implementation Guide 
Data Elements and Message Specification 
November  Implementation Guide for Electronic  5.0  Reached Step 4  E2B 
Transmission of Individual Case Safety 
2012  but no 
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 
history spreadsheet should be consulted for 
details of changes 
November  Editorial corrections and updates based on  5.02    E2B 
Q&A document 
2016  IWG 
 
   
 
-1-  Contains Nonbinding Recommendations 
 
 
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.
 
-2-  Contains Nonbinding Recommendations 
 
 
 
 
Table of Contents 
 
INTRODUCTION .................................................................................... 12 
1.0 Purpose ................................................................................................... 12 
1.1 Scope ............................................................................................................................ 13 
1.2 Business Case ............................................................................................................. 13 
2.0 Background ............................................................................................. 14 
2.1 General Background and History of ICH .................................................................. 14 
2.1.1 The ICH and its Partners ................................................................................... 14 
2.1.2 History of ICH ICSR guidelines ......................................................................... 14 
2.1.3 The Process of Revision in ICH .......................................................................... 14 
2.2 Development of ICSR Standard under Joint Initiative............................................ 15 
2.3 Background of Message Standard ............................................................................. 15 
2.4 Representation of the Electronic ICSR ...................................................................... 16 
2.4.1 Why Standardisation and Electronic ICSR Exchange are Needed ................. 16 
2.4.2 How ICSRs Are Presently Transmitted and the Advantages of Electronic Submissions .......... 17 
3.0 Essential Components ............................................................................ 19 
3.1 ICH ICSR Relational Diagrams ................................................................................. 19 
3.2 Code Sets, Terminologies and Vocabularies for E2B(R3) ........................................ 21 
3.2.1 Terminologies and Vocabularies Employed by the ICSR Message ................. 21 
3.2.2 ICH Maintained Code Sets and Object Identifiers (OIDs) Created for the ICH ICSR .............. 25 
3.2.3 International Standard Code Sets ..................................................................... 28 
3.3 ICH E2B(R3) Specifications for the Transmission of ICSRs ................................... 30 
3.3.1 Minimum Information ........................................................................................ 30 
3.3.2 Definition of Data Elements within a Message ................................................ 30 
3.3.3 General Principles .............................................................................................. 31 
3.3.4 Retransmission of cases ...................................................................................... 31 
3.3.5 Notes on Format of Data Elements ................................................................... 32 
3.3.6 General rules for Data Entry ............................................................................. 32 
3.3.7 Details of ICH E2B(R3) Data Elements ............................................................ 36 
 
 
-3-  Contains Nonbinding Recommendations 
 
 
3.4 ICH E2B(R3)DATA ELEMENTS...................................................... 38 
N.1 ICH ICSR Transmission Identification (batch wrapper) ....................... 38 
N.1.1 Type of Messages in Batch ..................................................................................... 38 
N.1.2 Batch Number ......................................................................................................... 38 
N.1.3 Batch Sender Identifier .......................................................................................... 39 
N.1.4 Batch Receiver Identifier........................................................................................ 39 
N.1.5 Date of Batch Transmission ................................................................................... 39 
N.2.r ICH ICSR Message Header (message wrapper) (repeat as necessary) .. 40 
N.2.r.1 Message Identifier ................................................................................................ 40 
N.2.r.2 Message Sender Identifier ................................................................................... 41 
N.2.r.3 Message Receiver Identifier ................................................................................ 41 
N.2.r.4 Date of Message Creation .................................................................................... 41 
C.1 Identificationofthe Case Safety Report .................................................. 42 
C.1.1 Senders (case) Safety Report Unique Identifier ................................................... 43 
C.1.2 Date of Creation ...................................................................................................... 44 
C.1.3 Type of Report ......................................................................................................... 44 
C.1.4 Date Report Was First Received from Source ....................................................... 45 
C.1.5 Date of Most Recent Information for This Report................................................. 45 
C.1.6 Additional Available Documents Held by Sender ................................................. 45 
C.1.6.1 Are Additional Documents Available? ........................................................... 46 
C.1.6.1.r Documents Held by Sender (repeat as necessary) ...................................... 46 
C.1.7 Does This Case Fulfil the Local Criteria for an Expedited Report? .................... 47 
C.1.8 Worldwide Unique Case Identification .................................................................. 47 
C.1.8.1 Worldwide Unique Case Identification Number ........................................... 48 
C.1.8.2 First Sender of This Case ............................................................................... 48 
C.1.9 Other Case Identifiers ............................................................................................ 49 
C.1.10.r  Identification Number of the Report Linked to This Report (repeat as necessary) ....... 51 
C.1.11 Report Nullification / Amendment ....................................................................... 51 
   
 
-4-  Contains Nonbinding Recommendations 
 
 
C.2.r Primary Source(s) of Information (repeat as necessary) ...................... 53 
C.2.r.1 Reporters Name ................................................................................................... 54 
C.2.r.2 Reporters Address and Telephone ...................................................................... 55 
C.2.r.3 Reporters Country Code ...................................................................................... 57 
C.2.r.4 Qualification ......................................................................................................... 58 
C.2.r.5 Primary Source for Regulatory Purposes ............................................................ 58 
C.3 Information on Sender of Case Safety Report ........................................ 59 
C.3.1 Sender Type ............................................................................................................. 59 
C.3.2 Senders Organisation ............................................................................................. 60 
C.3.3 Person Responsible for Sending the Report .......................................................... 60 
C.3.4 Senders Address, Fax, Telephone and E-mail Address ....................................... 61 
C.4.r Literature Reference(s) (repeat as necessary) ..................................... 65 
C.4.r.1 Literature Reference(s) ........................................................................................ 65 
C.4.r.2 Included Documents ............................................................................................. 65 
C.5 Study Identification ............................................................................... 66 
C.5.1.r Study Registration (repeat as necessary) ........................................................... 66 
C.5.1.r.1 Study Registration Number ......................................................................... 66 
C.5.1.r.2 Study Registration Country ......................................................................... 66 
C.5.2 Study Name ............................................................................................................. 67 
C.5.3 Sponsor Study Number ........................................................................................... 67 
C.5.4 Study Type Where Reaction(s) / Event(s) Were Observed ................................... 67 
D Patient Characteristics ............................................................................. 69 
D.1 Patient (name or initials) .......................................................................................... 73 
D.1.1 Patient Medical Record Number(s) and Source(s) of the Record Number ................. 73 
D.2 Age Information ......................................................................................................... 75 
D.2.1 Date of Birth ....................................................................................................... 75 
D.2.2 Age at Time of Onset of Reaction / Event ......................................................... 75 
D.2.2.1a Gestation Period When Reaction / Event Was Observed in the Foetus ................ 76 
D.2.3 Patient Age Group (as per reporter) ................................................................. 77 
D.3 Body Weight (kg) ........................................................................................................ 77 
D.4 Height (cm) ................................................................................................................. 78 
D.5 Sex ............................................................................................................................... 78 
D.6 Last Menstrual Period Date ...................................................................................... 78 
 
-5-  Contains Nonbinding Recommendations 
 
 
D.7 Relevant Medical History and Concurrent Conditions (not including reaction / event) ..... 79 
D.7.1.r Structured Information on Relevant Medical History (repeat as necessary)79 
D.7.2 Text for Relevant Medical History and Concurrent Conditions ..................... 81 
D.7.3 Concomitant Therapies ...................................................................................... 81 
D.8.r Relevant Past Drug History (repeat as necessary) ............................................... 82 
D.8.r.1 Name of Drug as Reported .............................................................................. 84 
D.8.r.2 Medicinal Product Identifier (MPID) ............................................................. 84 
D.8.r.3 Pharmaceutical Product Identifier (PhPID) .................................................. 85 
D.8.r.4 Start Date ........................................................................................................ 85 
D.8.r.5 End Date .......................................................................................................... 85 
D.8.r.6 Indication (MedDRA code) .............................................................................. 86 
D.8.r.7 Reaction (MedDRA code)................................................................................. 86 
D.9 In Case of Death ......................................................................................................... 86 
D.9.1Date of Death....................................................................................................... 86 
D.9.2.r Reported Cause(s) of Death (repeat as necessary) ........................................ 87 
D.9.2.r.1b Reported Cause(s) of Death (MedDRA code) ............................................ 87 
D.9.2.r.2 Reported Cause(s) of Death (free text) ........................................................ 87 
D.9.3 Was Autopsy Done? ............................................................................................ 88 
D.9.4.r Autopsy-determined Cause(s) of Death (repeat as necessary) ..................... 88 
D.10 For a Parent-child / Foetus Report, Information Concerning the Parent ...... 89 
D.10.1 Parent Identification ............................................................................................. 89 
D.10.2 Parent Age Information ........................................................................................ 89 
D.10.2.1 Date of Birth of Parent ................................................................................. 89 
D.10.2.2 Age of Parent ................................................................................................. 89 
D.10.3 Last Menstrual Period Date of Parent ................................................................ 90 
D.10.4 Body Weight (kg) of Parent .................................................................................. 90 
D.10.5 Height (cm) of Parent ........................................................................................... 90 
D.10.6 Sex of Parent ......................................................................................................... 91 
D.10.7 Relevant Medical History and Concurrent Conditions of Parent ...................... 91 
D.10.7.1.r Structured Information of Parent (MedDRA code) (repeat as necessary).. 91 
D.10.7.2 Text for Relevant Medical History and Concurrent Conditions of Parent ............ 92 
D.10.8.r Relevant Past Drug History of Parent (repeat as necessary) .......................... 93 
D.10.8.r.1 Name of Drug as Reported ......................................................................... 93 
 
-6-  Contains Nonbinding Recommendations 
 
 
D.10.8.r.2 Medicinal Product Identifier (MPID) ........................................................ 93 
D.10.8.r.3 Pharmaceutical Product Identifier (PhPID) ............................................. 94 
D.10.8.r.4 Start Date ................................................................................................... 94 
D.10.8.r.5 End Date ..................................................................................................... 94 
D.10.8.r.6 Indication (MedDRA code) ......................................................................... 95 
D.10.8.r.7 Reactions (MedDRA code) .......................................................................... 95 
E.i REACTION(S)/EVENT(S) (REPEAT AS NECESSARY) ................. 96 
E.i.1 Reaction / Event as Reported by the Primary Source ............................................ 97 
E.i.1.1 Reaction / Event as Reported by the Primary Source in Native Language .............. 97 
E.i.1.2 Reaction / Event as Reported by the Primary Source for Translation ......... 97 
E.i.2.1 Reaction / Event (MedDRA code) ......................................................................... 97 
E.i.3.1 Term Highlighted by the Reporter....................................................................... 98 
E.i.3.2 Seriousness Criteria at Event Level (more than one can be chosen) ................ 98 
E.i.3.2a Results in Death ............................................................................................. 98 
E.i.3.2b Life Threatening............................................................................................. 99 
E.i.3.2c Caused / Prolonged Hospitalisation .............................................................. 99 
E.i.3.2d Disabling / Incapacitating ............................................................................. 99 
E.i.3.2e Congenital Anomaly / Birth Defect ............................................................. 100 
E.i.3.2f Other Medically Important Condition ......................................................... 100 
E.i.4 Date of Start of Reaction / Event .......................................................................... 100 
E.i.5 Date of End of Reaction / Event ............................................................................ 101 
E.i.6 Duration of Reaction / Event ................................................................................. 101 
E.i.7 Outcome of Reaction / Event at the Time of Last Observation ........................... 102 
E.i.8 Medical Confirmation by Healthcare Professional .............................................. 102 
E.i.9 Identification of the Country Where the Reaction / Event Occurred ................. 103 
F.r Results of Tests and Procedures Relevant to the Investigation of the Patient (repeat as necessary) ...... 103 
F.r.1 Test Date ................................................................................................................ 104 
F.r.2 Test Name .............................................................................................................. 104 
F.r.2.1 Test Name (free text) ..................................................................................... 104 
F.r.2.2 Test Name (MedDRA code) ........................................................................... 104 
F.r.3 Test Result ............................................................................................................. 105 
F.r.3.1 Test Result (code) ........................................................................................... 105 
F.r.3.2 Test Result (value / qualifier) ........................................................................ 106 
 
-7-  Contains Nonbinding Recommendations 
 
 
F.r.3.3 Test Result (unit) ........................................................................................... 106 
F.r.3.4 Result Unstructured Data (free text) ........................................................... 106 
F.r.4 Normal Low Value ................................................................................................. 107 
F.r.5 Normal High Value ................................................................................................ 107 
F.r.6 Comments (free text) ............................................................................................. 107 
F.r.7 More Information Available .................................................................................. 108 
G.k DRUG(S) INFORMATION (REPEAT AS NECESSARY) ............. 109 
G.k.1 Characterisation of Drug Role ............................................................................. 111 
G.k.2 Drug Identification ............................................................................................... 112 
G.k.2.1 Medicinal Product Unique Identifier/Pharmaceutical Product Unique Identifier ... 113 
G.k.2.2 Medicinal Product Name as Reported by the Primary Source .................. 114 
G.k.2.3.r Substance / Specified Substance Identifier and Strength (repeat as necessary) .... 114 
G.k.3 Holder and Authorisation / Application Number of Drug .................................. 117 
G.k.3.1 Authorisation / Application Number ........................................................... 117 
G.k.3.2 Country of Authorisation / Application ....................................................... 117 
G.k.3.3 Name of Holder / Applicant .......................................................................... 118 
G.k.4.r Dosage and Relevant Information (repeat as necessary) ................................ 118 
G.k.4.r.1a Dose (number) .......................................................................................... 119 
G.k.4.r.1b Dose (unit) ................................................................................................. 119 
G.k.4.r.2 Number of Units in the Interval ............................................................... 119 
G.k.4.r.3 Definition of the Time Interval Unit ......................................................... 119 
G.k.4.r.4 Date and Time of Start of Drug ................................................................. 119 
G.k.4.r.5 Date and Time of Last Administration ..................................................... 120 
G.k.4.r.6 Duration of Drug Administration .............................................................. 120 
G.k.4.r.7 Batch / Lot Number .................................................................................... 121 
G.k.4.r.8 Dosage Text ................................................................................................ 121 
G.k.4.r.9 Pharmaceutical Dose Form ....................................................................... 122 
G.k.4.r.10 Route of Administration .......................................................................... 123 
G.k.4.r.11 Parent Route of Administration (in case of a parent child / foetus report) . 123 
G.k.5 Cumulative Dose to First Reaction ...................................................................... 125 
G.k.6 Gestation Period at Time of Exposure ................................................................. 125 
G.k.7.r Indication for Use in Case (repeat as necessary) ............................................. 126 
G.k.7.r.1 Indication as Reported by the Primary Source ........................................ 126 
 
-8-  Contains Nonbinding Recommendations 
 
 
G.k.7.r.2 Indication (MedDRA code) ......................................................................... 126 
G.k.8 Action(s) Taken with Drug ................................................................................... 127 
G.k.9.i Drug-reaction(s) / Event(s) Matrix (repeat as necessary) ................................ 127 
G.k.9.i.1 Reaction(s) / Event(s) Assessed .................................................................. 128 
G.k.9.i.2 Assessment of Relatedness of Drug to Reaction(s)/Event(s) ...................... 129 
G.k.9.i.3 Time Interval between Beginning of Drug Administration and Start of Reaction / Event 130 
G.k.9.i.4 Did Reaction Recur on Re-administration? ............................................... 131 
G.k.10.r Additional Information on Drug (coded) (repeat as necessary) ..................... 131 
G.k.11 Additional Information on Drug (free text) ....................................................... 131 
H NARRATIVE CASE SUMMARY AND FURTHER INFORMATION133 
H.1 Case Narrative Including Clinical Course, Therapeutic Measures, Outcome and 
Additional Relevant Information ................................................................................... 133 
H.2 Reporter's Comments .............................................................................................. 134 
H.3.r Sender's Diagnosis (MedDRA code) (repeat as necessary) ................................. 134 
H.4 Sender's Comments ................................................................................................. 135 
H.5.r Case Summary and Reporters Comments in Native Language (repeat as necessary) ..... 135 
H.5.r.1a Case Summary and Reporters Comments Text ....................................... 135 
H.5.r.1b Case Summary and Reporters Comments Language .............................. 135 
3.5 DOCUMENT ATTACHMENTS ...................................................... 136 
3.5.1 User Guidance ........................................................................................................ 136 
3.5.2 Technical specification........................................................................................... 136 
3.5.3 Examples of XML instances .................................................................................. 136 
4.0 THE ICSR ACKNOWLEDGEMENT TRANSACTION ................. 138 
4.1 Acknowledgement Message in HL7 ......................................................................... 138 
4.2 ICH ICSR Acknowledgement Message ................................................................... 138 
ACK.M / A ICH ICSR Batch Acknowledgement ......................................... 140 
ACK.M.1 Acknowledgement Batch Number ................................................................. 140 
ACK.M.2 Acknowledgement Batch Sender Identifier .................................................. 140 
ACK.M.3 Acknowledgement Batch Receiver Identifier ............................................... 141 
ACK.M.4 Acknowledgement Date of Batch Transmission ........................................... 141 
ACK.A.1 ICSR Batch Number ....................................................................................... 142 
ACK.A.2 Acknowledgement Local Message Number ................................................... 142 
ACK.A.3 Date of ICSR Batch Transmission ................................................................. 142 
 
-9-  Contains Nonbinding Recommendations 
 
 
ACK.A.4 Transmission Acknowledgement Code .......................................................... 143 
ACK.A.5 Batch Validation Error ................................................................................... 143 
ACK.B ICH ICSR Message Acknowledgement ........................................... 143 
ACK.B.r.1 ICSR Message Number ................................................................................ 143 
ACK.B.r.2 Local Report Number ................................................................................... 143 
ACK.B.r.3 ICSR Message ACK Receiver....................................................................... 144 
ACK.B.r.4 ICSR Message ACK Sender ......................................................................... 144 
ACK.B.r.5 Date of ICSR Message Creation .................................................................. 144 
ACK.B.r.6 Acknowledgement Code for a ICSR Message ............................................. 145 
ACK.B.r.7 Error / Warning Message or Comment ....................................................... 145 
APPENDICES ....................................................................................... 146 
APPENDIX I  PREPARING AND SENDING ICH ICSRS: ...................... 146 
Appendix I (A)  ICH ICSR SCHEMAs ......................................................................... 146 
1. List of schemas for ICH ICSR messages and ICSR Acknowledgement messages .......... 146 
2. User Guidance for each ICH ICSR schemas ........................................................ 146 
Appendix I (B)  Backwards & Forwards Compatibility ............................................. 151 
Appendix I (C)  Schema files ........................................................................................ 151 
Appendix I (D)  Reference Instances for ICH ICSR message and ICSR Acknowledgement message 151 
Appendix I (E)  Example Instances of report cases .................................................... 151 
Appendix I (F)  ICH E2B code lists .............................................................................. 151 
Appendix I (G)  Technical Information ........................................................................ 151 
Appendix I (H)  SGML & XML conversion .................................................................. 151 
APPENDIX II  DATE / TIME ................................................................... 152 
Appendix II (A) Date / Time ........................................................................................... 152 
Appendix II (B) Time Zone ............................................................................................. 153 
Appendix II (C) ISO 8601 Compliant XML Examples ................................................. 153 
APPENDIX III - ABBREVIATIONS and GLOSSARY OF TERMS ........... 154 
Appendix III (A)ABBREVIATIONS .............................................................................. 154 
Appendix III (B) GLOSSARY of TERMS ...................................................................... 156 
 
-10-  Contains Nonbinding Recommendations 
 
 
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.
 
-11-  Contains Nonbinding Recommendations 
 
 
 
Introduction 
1
This document is a guide for implementing the standard adopted by the ICH  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. 
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 
 
1The International Council for Harmonisation of Technical Requirements for Pharmaceuticals for 
Human Use (ICH) http://www.ich.org/ 
 
-12-  Contains Nonbinding Recommendations 
 
 
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. 
 
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. 
 
 
-13-  Contains Nonbinding Recommendations 
 
 
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 GS12.  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 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. 
 
 
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. 
 
-14-  Contains Nonbinding Recommendations 
 
 
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 ICHs 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 ICHs 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. 
 
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 
 
-15-  Contains Nonbinding Recommendations 
 
 
3
Model -- Release 1.  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. 
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. 
 
3 Available from the HL7 Website, at http://www.hl7.org 
 
-16-  Contains Nonbinding Recommendations 
 
 
 
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. 
4
2.4.2.1 Markup Languages  
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.   
 
 
4Co-existence of Traditional EDI with XML-EDI, Skip Stein, Management Systems Consulting, 
Inc., http://www.msc-inc.net/ 
 
-17-  Contains Nonbinding Recommendations 
 
 
In general, DTDs perform well when applied to documents or text-intensive information.XML 
5
schema work best for data-intensive information .  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 
6
be manipulated, stored, and indexed, which is a practical advantage . 
 
Another advantage to XML is that Unicode is universally present in all XML parsers.  Except for 
7
more recent ones, most SGML parsers do not provide Unicode support .  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 
8
browser or word processor.  In this way, translation between languages is built into the use of XML .   
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, 
9
remain accessible . 
 
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. 
 
5Tittel, Ed, Pitts, Natanya, and Boumphrey, Frank.XML for Dummies.   New York: Wiley Publishing, 
Inc., 2002. 
6Beyond the SGML DTD, Francois CHAHUNEAU, Directeur General/General Manager, AIS S.A., 
15-17 rue Remy Dumoncel, 75014, Paris, FRANCE, http://xml.coverpages.org/chahuneauXML.html 
7XML: What HTML Wanted to Be!, Norma  Haakonstad, National Accounts Manager, Arbortext, 
Inc., 1000 Victors Way, Ann Arbor  (Michigan) 48108 
8Unicode.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/ 
 
-18-  Contains Nonbinding Recommendations 
 
 
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 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. 
 
 
-19-  Contains Nonbinding Recommendations 
 
 
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
 
 
-20-  Contains Nonbinding Recommendations 
 
 
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 
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 
 
-21-  Contains Nonbinding Recommendations 
 
 
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. 
 
 
-22-  Contains Nonbinding Recommendations 
 
 
Table 1: E2B (R3) data elements and IDMP OIDs 
Element id  Element Name  OID Reference10 
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 
11
data related to the safe use of medical products .   
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. 
 
Table 2: E2B (R3) data elements and MedDRA OIDs 
 
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. 
 
-23-  Contains Nonbinding Recommendations 
 
 
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) 
 
 
-24-  Contains Nonbinding Recommendations 
 
 
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) 
 
 
-25-  Contains Nonbinding Recommendations 
 
 
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. 
 
-26-  Contains Nonbinding Recommendations 
 
 
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 
Senders (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 
 
 
 
-27-  Contains Nonbinding Recommendations 
 
 
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 form12 
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/ 
 
-28-  Contains Nonbinding Recommendations 
 
 
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 Reporters 
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. 
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. 
 
-29-  Contains Nonbinding Recommendations 
 
 
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 patients 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 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: 
 
 
-30-  Contains Nonbinding Recommendations 
 
 
  Senders (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);  
  Reporters Country Code (C.2.r.3);  
  Senders 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. 
 
There are certain exceptions and the following data elements might be updated: 
  Senders (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); 
 
-31-  Contains Nonbinding Recommendations 
 
 
  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 
  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.   
o
  Section B 
  D - Patient Characteristics; 
o
  E - Reaction(s)/ Event(s); 
o
  F - Results of Tests and Procedures Relevant to the Investigation of the Patient; 
o
  G - Drug(s) Information; and 
o
  H - Narrative Case Summary and Further Information. 
o
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. 
 
-32-  Contains Nonbinding Recommendations 
 
 
 
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 Reporters Comments in 
Native Language(H.5.r)) are to be provided in English for international 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: 
 
 
-33-  Contains Nonbinding Recommendations 
 
 
  The data type for each element will be described as follows: 
  A=Alpha: This data type is primarily used within the ICSR for certain data elements that 
o
require controlled vocabulary, such as the Reporters 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; 
  AN=AlphaNumeric: String data element that can contain alphabetic, numerical and special 
o
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 
  N=numeric: String data element that contains only the characters 0-9.E+- used to represent an 
o
integer or floating point numbers, including scientific notation.  Example: 1.23E-1 or 34192 
or 32.12.Commas are not permitted. 
  Date: See Appendix II (A) 
o
  Boolean: Boolean values are represented by: 
o
 false which can also equate to no; 
 true which can also equate to yes*; 
 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.   
  Some elements might need to be transmitted as part of a valid ICSR yet might need to be empty 
o
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. 
  nullFlavors: ICH ICSR uses the following codes from the HL7 Messaging Standard to 
o
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 exceptional 
No 
NI  value.  This is the most general exceptional value.  It is also the 
Information 
default exceptional value.   
 
-34-  Contains Nonbinding Recommendations 
 
 
Code  Name  Definition 
There is information on this item available but it has not been 
provided by the sender due to security, privacy or other reasons.  
There could be an alternate mechanism for gaining access to this 
information.  Note: using this nullFlavor can provide information 
MSK  Masked 
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 menstrual 
NA 
Applicable  period for a male). 
Asked But  Information was sought but not found (e.g. patient was asked but 
ASKU 
Unknown  didn't know) 
NASK  Not Asked  This information has not been sought (e.g. patient was not asked) 
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"> 
 
-35-  Contains Nonbinding Recommendations 
 
 
<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: 
  the data element number; 
  For the purpose of this IG, data elements for the Acknowledgement message will be preceded 
o
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). 
 
 
-36-  Contains Nonbinding Recommendations 
 
 
 
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. 
 
-37-  Contains Nonbinding Recommendations 
 
 
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. 
 
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 
 
-38-  Contains Nonbinding Recommendations 
 
 
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.    
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. 
 
-39-  Contains Nonbinding Recommendations 
 
 
(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"/> 
 
-40-  Contains Nonbinding Recommendations 
 
 
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 senders 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]). 
 
-41-  Contains Nonbinding Recommendations 
 
 
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      - Senders (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
 
 
 
-42-  Contains Nonbinding Recommendations 
 
 
C.1.1 Senders (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 
senders organisation; the use of a - (dash/hyphen) should be avoided in 
this segment.  The report number is the organisations 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 companys 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 
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
 
-43-  Contains Nonbinding Recommendations 
 
 
-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]) 
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 
 
-44-  Contains Nonbinding Recommendations 
 
 
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. 
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 
 
-45-  Contains Nonbinding Recommendations 
 
 
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. 
 
 
C.1.6.1.r Documents Held by Sender (repeat as necessary) 
 
-46-  Contains Nonbinding Recommendations 
 
 
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 receivers 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 senders 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 receivers 
countrys 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. 
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.   
 
 
-47-  Contains Nonbinding Recommendations 
 
 
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 senders (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. 
 
 
Retransmitters should use their own Senders (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 
 
-48-  Contains Nonbinding Recommendations 
 
 
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. 
 
 
 
 
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 
 
-49-  Contains Nonbinding Recommendations 
 
 
User Guidance  This repeatable data element should be used in conjunction with 
C.1.9.1.r.2 to provide all sources (organisations 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. 
 
-50-  Contains Nonbinding Recommendations 
 
 
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 Senders (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 
Senders (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 
OID  2.16.840.1.113883.3.989.2.1.1.5 
Value Allowed  1=Nullification 
2=Amendment 
 
-51-  Contains Nonbinding Recommendations 
 
 
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)   
   
 
   
 
-52-  Contains Nonbinding Recommendations 
 
 
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 - Reporters Title
C.2.r.1.2 - Reporters Given Name
C.2.r.1.3 - Reporters Middle Name
C.2.r.1.4 - Reporters Family Name
C.2.r.2.1 - Reporters Organisation
C.2.r.2.2 - Reporters Department
C.2.r.2.3 - Reporters Street Address
C.2.r.2.4 - Reporters City
C.2.r.2.5 - Reporters State or Province
C.2.r.2.6 - Reporters Postcode
C.2.r.2.7 - Reporters Telephone
C.2.r.3    - Reporters Country Code
C.2.r.4    - Qualification
C.2.r.5    - Primary Source for Regulatory Purposes
 
 
Primary 
Reporters  Reporters 
Reporters  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 reporters 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 
reporter request.  Please see Section 3.3.6 for further guidance on the use of 
nullFlavor to describe missing or non-transmitted information. 
 
-53-  Contains Nonbinding Recommendations 
 
 
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 Reporters Name 
C.2.r.1.1 Reporters 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 Reporters 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. 
 
 
 
 
C.2.r.1.3 Reporters Middle Name 
 
-54-  Contains Nonbinding Recommendations 
 
 
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 reporters given name and the 
second given name tag captures reporters 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 Reporters 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 Reporters Address and Telephone 
C.2.r.2.1 Reporters Organisation 
User Guidance  This data element captures the reporter's organisations 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.2 Reporters Department 
User Guidance  This data element captures the reporter's department name. 
Conformance  Optional 
 
-55-  Contains Nonbinding Recommendations 
 
 
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 Reporters 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 Reporters 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 Reporters 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. 
 
 
 
C.2.r.2.6 Reporters Postcode 
User Guidance  This data element captures the reporter's postcode. 
Conformance  Optional 
Data Type  15AN 
OID  None 
 
-56-  Contains Nonbinding Recommendations 
 
 
Value Allowed  Free text 
nullFlavor: MSK, ASKU, NASK 
Business Rule(s)    
  See the business rules for C.2.r. 
C.2.r.2.7 Reporters 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 Reporters 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 reporters 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. 
 
-57-  Contains Nonbinding Recommendations 
 
 
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 reporters 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. 
 
-58-  Contains Nonbinding Recommendations 
 
 
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    - Senders Organisation
C.3.3.1 - Senders Department
C.3.3.2 - Senders Title
C.3.3.3 - Senders Given Name
C.3.3.4 - Senders Middle Name
C.3.3.5 - Senders Family Name
C.3.4.1 - Senders Street Address
C.3.4.2 - Senders City
C.3.4.3 - Senders State or Province
C.3.4.4 - Senders Postcode
C.3.4.5 - Senders Country Code
C.3.4.6 - Senders Telephone
C.3.4.7 - Senders Fax
C.3.4.8 - Senders 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)   
   
 
-59-  Contains Nonbinding Recommendations 
 
 
C.3.2 Senders Organisation 
User Guidance  This data element captures the senders 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 
Senders   Senders  Senders  Senders  Senders 
 
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 Senders Department 
User Guidance  This data element captures the name of the senders 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 Senders Title 
User Guidance  This data element captures the senders title. 
Conformance  Optional 
Data Type  50AN 
OID  None 
Value Allowed  Free text 
Business Rule(s)   
  See the business rules for C.3.3. 
C.3.3.3 Senders Given Name 
 
-60-  Contains Nonbinding Recommendations 
 
 
User Guidance  This data element captures the senders 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 Senders 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 senders given name and the second 
given name tag captures senders 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 Senders 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. 
C.3.4 Senders Address, Fax, Telephone and E-mail Address 
Senders  Senders  Senders  Senders 
Senders  Senders  Senders  Senders 
  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.   
 
-61-  Contains Nonbinding Recommendations 
 
 
Business   
Rule(s) 
  See the business rules for C.3.3. 
C.3.4.1 Senders 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 Senders 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 Senders 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. 
   
 
-62-  Contains Nonbinding Recommendations 
 
 
C.3.4.4 Senders 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 Senders 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 senders 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 Senders Telephone 
User Guidance  This data element captures the senders 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. 
   
 
-63-  Contains Nonbinding Recommendations 
 
 
C.3.4.7 Senders Fax 
User Guidance  This data element captures the senders 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 Senders E-mail Address 
User Guidance  This data element captures the senders email address. 
Conformance  Optional 
Data Type  100AN 
OID  None 
Value Allowed  Free text 
Business Rule(s)   
  See the business rules for C.3.3. 
 
   
 
-64-  Contains Nonbinding Recommendations 
 
 
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 receivers system may have particular configurations on 
handling attachments, Value Allowed is defined by each region. 
 
 
 
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.   
 
-65-  Contains Nonbinding Recommendations 
 
 
 
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. 
 
 
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. 
 
-66-  Contains Nonbinding Recommendations 
 
 
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. 
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 
 
-67-  Contains Nonbinding Recommendations 
 
 
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)   
   
 
 
-68-  Contains Nonbinding Recommendations 
 
 
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 mothers 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 mothers case.  The data element C.1.10.r should be completed for both cases 
(e.g. the mothers and babys). 
  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 distress.  The 
Caesarean section should not be considered an adverse event/reaction for the mother.  The 
mothers 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 
 
-69-  Contains Nonbinding Recommendations 
 
 
reflect the mothers information in Section D.10 and the case narrative (Section H.1) should 
describe the entire case, including the fathers information. 
 
-70-  Contains Nonbinding Recommendations 
 
 
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
 
 
-71-  Contains Nonbinding Recommendations 
 
 
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)
 
   
 
-72-  Contains Nonbinding Recommendations 
 
 
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"/> 
 
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. 
 
-73-  Contains Nonbinding Recommendations 
 
 
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. 
   
 
-74-  Contains Nonbinding Recommendations 
 
 
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. 
 
D.2.2 Age at Time of Onset of Reaction / Event 
 
-75-  Contains Nonbinding Recommendations 
 
 
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 60s. 
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)   
   
 
   
 
-76-  Contains Nonbinding Recommendations 
 
 
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. 
 
   
 
-77-  Contains Nonbinding Recommendations 
 
 
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 mothers 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. 
 
   
 
-78-  Contains Nonbinding Recommendations 
 
 
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)   
   
D.7.1.r.2 Start Date 
 
-79-  Contains Nonbinding Recommendations 
 
 
User Guidance  This data element captures the start date of the patients 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 patients 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.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. 
 
-80-  Contains Nonbinding Recommendations 
 
 
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 
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 
 
-81-  Contains Nonbinding Recommendations 
 
 
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. 
 
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. 
 
 
-82-  Contains Nonbinding Recommendations 
 
 
 
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.   
 
 
   
 
-83-  Contains Nonbinding Recommendations 
 
 
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)   
   
 
 
-84-  Contains Nonbinding Recommendations 
 
 
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. 
 
   
 
-85-  Contains Nonbinding Recommendations 
 
 
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)   
   
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 
 
-86-  Contains Nonbinding Recommendations 
 
 
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)   
   
 
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)   
   
 
-87-  Contains Nonbinding Recommendations 
 
 
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)   
   
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)   
   
 
   
 
-88-  Contains Nonbinding Recommendations 
 
 
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)   
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 
 
-89-  Contains Nonbinding Recommendations 
 
 
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 
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)   
 
-90-  Contains Nonbinding Recommendations 
 
 
  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. 
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. 
 
-91-  Contains Nonbinding Recommendations 
 
 
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.   
 
 
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 
 
-92-  Contains Nonbinding Recommendations 
 
 
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. 
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 
 
-93-  Contains Nonbinding Recommendations 
 
 
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)   
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. 
 
-94-  Contains Nonbinding Recommendations 
 
 
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 
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)   
   
 
   
 
-95-  Contains Nonbinding Recommendations 
 
 
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
 
   
 
-96-  Contains Nonbinding Recommendations 
 
 
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. 
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 
 
-97-  Contains Nonbinding Recommendations 
 
 
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. 
E.i.3.2a Results in Death 
User Guidance  See Section E.i.3.2. 
Conformance  Required 
Data Type  Boolean 
OID  None 
 
-98-  Contains Nonbinding Recommendations 
 
 
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)   
   
 
   
 
-99-  Contains Nonbinding Recommendations 
 
 
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. 
 
   
 
-100-  Contains Nonbinding Recommendations 
 
 
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)   
   
 
   
 
-101-  Contains Nonbinding Recommendations 
 
 
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. 
 
   
 
-102-  Contains Nonbinding Recommendations 
 
 
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. 
 
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 
 
 
-103-  Contains Nonbinding Recommendations 
 
 
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 
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)   
   
 
-104-  Contains Nonbinding Recommendations 
 
 
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. 
 
   
 
-105-  Contains Nonbinding Recommendations 
 
 
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)   
   
 
   
 
-106-  Contains Nonbinding Recommendations 
 
 
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)   
   
 
   
 
-107-  Contains Nonbinding Recommendations 
 
 
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)   
   
 
   
 
-108-  Contains Nonbinding Recommendations 
 
 
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. 
 
 
-109-  Contains Nonbinding Recommendations 
 
 
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
 
 
 
 
-110-  Contains Nonbinding Recommendations 
 
 
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 
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 
 
-111-  Contains Nonbinding Recommendations 
 
 
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.   
   
 
-112-  Contains Nonbinding Recommendations 
 
 
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)   
   
 
   
 
-113-  Contains Nonbinding Recommendations 
 
 
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. 
   
 
-114-  Contains Nonbinding Recommendations 
 
 
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)   
   
 
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 
 
-115-  Contains Nonbinding Recommendations 
 
 
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. 
   
 
-116-  Contains Nonbinding Recommendations 
 
 
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 IDMP5 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. 
 
G.k.3.2 Country of Authorisation / Application 
 
-117-  Contains Nonbinding Recommendations 
 
 
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 fathers information.   
 
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) 
 
-118-  Contains Nonbinding Recommendations 
 
 
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 
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 
 
-119-  Contains Nonbinding Recommendations 
 
 
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) 
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. 
 
-120-  Contains Nonbinding Recommendations 
 
 
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 
Data Type  2000AN 
OID  None 
Value Allowed  Free text 
Business Rule(s)   
   
   
 
-121-  Contains Nonbinding Recommendations 
 
 
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)   
   
   
 
-122-  Contains Nonbinding Recommendations 
 
 
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 parents 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)   
   
G.k.4.r.11 Parent Route of Administration (in case of a parent child / foetus report) 
 
-123-  Contains Nonbinding Recommendations 
 
 
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 
parents 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)   
   
 
   
 
-124-  Contains Nonbinding Recommendations 
 
 
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}. 
 
   
 
-125-  Contains Nonbinding Recommendations 
 
 
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.  
 
   
 
-126-  Contains Nonbinding Recommendations 
 
 
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 reporters 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. 
 
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  
 
-127-  Contains Nonbinding Recommendations 
 
 
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 senders 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. 
 
   
 
-128-  Contains Nonbinding Recommendations 
 
 
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)   
   
 
   
 
-129-  Contains Nonbinding Recommendations 
 
 
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)   
   
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 
 
-130-  Contains Nonbinding Recommendations 
 
 
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)   
   
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)   
 
-131-  Contains Nonbinding Recommendations 
 
 
  If provided, this element needs to be separated and independent from any 
value selected in the code list for G.k.10.r. 
 
 
-132-  Contains Nonbinding Recommendations 
 
 
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 - Reporters comments
H.4 - Senders comments
H.3.r - Senders 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 Reporters Comments in Native Language 
0 ... n (repeat as necessary)
H.5.r.1a - Case Summary and Reporters Comments Text
H.5.r.1b - Case Summary and Reporters 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 Reporters or Senders 
comments. 
   
 
-133-  Contains Nonbinding Recommendations 
 
 
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)   
   
   
 
-134-  Contains Nonbinding Recommendations 
 
 
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 Reporters 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 reporters 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 senders and receivers comments in a 
language other than English, as required in some countries and regions. 
H.5.r.1a Case Summary and Reporters 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 Reporters 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)   
   
 
   
 
-135-  Contains Nonbinding Recommendations 
 
 
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). 
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. 
 
-136-  Contains Nonbinding Recommendations 
 
 
 
<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'>    
omSJUEdmde9j44zmMiromSJUEdmde9j44zmMirdMDSsWdIJdksIJR3373jeu836edjzMMIj
dMDSsWdIJdksIJR3373jeu83MNYD83jmMdomSJUEdmde9j44zmMir..MNYD83jmMdom
SJUEdmde9j44zmMir6edjzMMIjdMDSsWdIJdksIJR3373jeu834zmMir6edjzMMIjdMDSsW
dIJdksIJR3373jeu83== 
</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">    
omSJUEdmde9j44zmMiromSJUEdmde9j44zmMirdMDSsWdIJdksIJR3373jeu836edjzMMIj
dMDSsWdIJdksIJR3373jeu83MNYD83jmMdomSJUEdmde9j44zmMir..MNYD83jmMdom
SJUEdmde9j44zmMir6edjzMMIjdMDSsWdIJdksIJR3373jeu834zmMir6edjzMMIjdMDSsW
dIJdksIJR3373jeu83== 
</text> 
  </document> 
</reference> 
   
 
-137-  Contains Nonbinding Recommendations 
 
 
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. 
 
 
-138-  Contains Nonbinding Recommendations 
 
 
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. 
 
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
 
 
-139-  Contains Nonbinding Recommendations 
 
 
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: 
<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. 
 
-140-  Contains Nonbinding Recommendations 
 
 
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]) 
 
   
 
-141-  Contains Nonbinding Recommendations 
 
 
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. 
 
   
 
-142-  Contains Nonbinding Recommendations 
 
 
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 (Senders (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 
Value Allowed  Free text 
Business Rule(s)   
   
 
-143-  Contains Nonbinding Recommendations 
 
 
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). 
 
-144-  Contains Nonbinding Recommendations 
 
 
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)   
   
   
 
-145-  Contains Nonbinding Recommendations 
 
 
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 
Schemas for each Acknowledgement 
message 
 
2. User Guidance for each ICH ICSR schemas 
 
-146-  Contains Nonbinding Recommendations 
 
 
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 elements, 
Guidance  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 elements, 
Guidance  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 all 
Guidance  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. 
b. Send Batch Interaction  
ICSR Batch Interaction 
MCCI_IN200100UV01 
User  Sends a Batch, which groups 0 or more Messages for communication purposes 
Guidance  (ISO/HL7 27953-2). 
For ICH ICSR messages, this schema defines root element. 
 
-147-  Contains Nonbinding Recommendations 
 
 
MCCI_ MT200100UV 
User  The Batch class functions in similar way to the Message class in an individual V3 
Guidance  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 message.   
Guidance   
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 to 
Guidance  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). 
PORR_MT049016UV 
User  The Human Pharmaceuticals Base Model RMIM is designed to support a report 
Guidance  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 acts 
Guidance  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, 
 
-148-  Contains Nonbinding Recommendations 
 
 
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 specified 
Guidance  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). 
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. 
 
-149-  Contains Nonbinding Recommendations 
 
 
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 drug 
Guidance  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 Batch 
Guidance  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. 
 MCCI_MT200101UV 
User 
A Response Batch can be used for (1) batches of accept acknowledgements, (2) 
Guidance 
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. 
 
-150-  Contains Nonbinding Recommendations 
 
 
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. 
 
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. 
   
 
-151-  Contains Nonbinding Recommendations 
 
 
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. 
 
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: 
 
 
-152-  Contains Nonbinding Recommendations 
 
 
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) 
 
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 
 
-153-  Contains Nonbinding Recommendations 
 
 
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  Comite Europeen 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) 
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 
 
-154-  Contains Nonbinding Recommendations 
 
 
Abbreviations  Definition 
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. 
 
-155-  Contains Nonbinding Recommendations 
 
 
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] 
 
-156-  Contains Nonbinding Recommendations 
 
 
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] 
 
13World Health Organisation International Medical Products Anti-Counterfeiting Task Force 
(IMPACT)http://www.who.int/impact/FinalBrochureWHA2008a.pdf 
 
-157-  Contains Nonbinding Recommendations 
 
 
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)] 
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] 
 
-158-  Contains Nonbinding Recommendations 
 
 
Term  Definition 
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] 
 
 
-159-