140
ICH ICSR Implementation Guide 12 April 2013
-141-
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 ‘true’ and a description of that document is required in C.1.6.1.r.1.Furthermore, an
electronic version of that document can be attached to the ICSR 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 version of the document (e.g. journal article) is attached to
the ICSR 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.
Because documents might not be available at the time of ICSR reporting, attachments can be
transmitted separately from the ICSR transmission. When the sender transmits an attachment
later, the original ICSR along with all the same medical information captured in E2B(R3) data
elements is retransmitted as an ‘amendment’ (See the guidance for C.1.11.1) If the data
elements in E2B(R3) have changed, then the ICSR with attachment is transmitted as a follow-up.
3.5.2 Technical specification
It is always required that ‘attached’ documents to an ICH ICSR be provided in-line therefore,
providing a hyperlink to the document source 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.
ICH ICSR Implementation Guide 12 April 2013
-141-
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 ‘true’ and a description of that document is required in C.1.6.1.r.1.Furthermore, an
electronic version of that document can be attached to the ICSR 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 version of the document (e.g. journal article) is attached to
the ICSR 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.
Because documents might not be available at the time of ICSR reporting, attachments can be
transmitted separately from the ICSR transmission. When the sender transmits an attachment
later, the original ICSR along with all the same medical information captured in E2B(R3) data
elements is retransmitted as an ‘amendment’ (See the guidance for C.1.11.1) If the data
elements in E2B(R3) have changed, then the ICSR with attachment is transmitted as a follow-up.
3.5.2 Technical specification
It is always required that ‘attached’ documents to an ICH ICSR be provided in-line therefore,
providing a hyperlink to the document source 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.