Food and Drug Administration

Center for Devices and Radiological Health

eMDR – electronic Medical Device Reporting

Health Level Seven (HL7 v3)
Individual Case Safety Report (ICSR R2)
Implementation Specifications

March 23, 2020

0
Table of Contents

Section I: Introduction...................................................................................................................2
Section II: eMDR Overview...........................................................................................................2
II.1 Health Level Seven: Standards Development Organization.................................................2
II.2 ICSR: Individual Case Safety Report.....................................................................................3
II.3 FDA Electronic Submissions Gateway (ESG)........................................................................3
II.4 ICSR and eMDR.......................................................................................................................4
Section III: Technical Section.......................................................................................................5
III.1 Health Level Seven Version 3..................................................................................................5
III.2 ICSR: Device Implementation.................................................................................................6
III.3 ICSR Message Contents...........................................................................................................7
III.4 Vocabulary................................................................................................................................9
III.5 Data Types..............................................................................................................................11
III.6 How To Create an MDR as an HL7 ICSR XML File..........................................................11
III.7 How to Validate Your ICSR Message...................................................................................12
Glossary...............................................................................................................................................14
Hyperlinks.....................................................................................................................................15
Frequently Asked Questions.........................................................................................................16
FDA Electronic Submissions Gateway (ESG)...................................................................................16
Message Content..................................................................................................................................18
Testing Process....................................................................................................................................25
Other Questions...................................................................................................................................27

1
Section I: Introduction
The Food and Drug Administration (FDA), Center for Devices and Radiological Health (CDRH)
initiated the eMDR (electronic Medical Device Reporting) project to enable reporters to
voluntarily submit medical device adverse event reports (MDRs) electronically. eMDR will
accept electronic medical device reports via two options, one designed for low-volume reporting
(infrequent or few reports) and one designed for high-volume reporting (frequent or numerous
reports).

Low-volume reporters can submit MDRs by downloading CDRH’s electronic submission tool,
eSubmitter software. For more information, please visit
http://www.fda.gov/ForIndustry/FDAeSubmitter/default.htm.

High-volume reporting can be carried out by submitting MDRs either as a batch (one or more
reports in one XML file) or individually (one report in an XML file), using the Health Level
Seven (HL7) Individual Case Safety Report (ICSR) standard, Release 2. This document
describes electronic reporting of high-volume MDRs to FDA. Implementation specifications are
provided via a package of files and are referenced throughout this document. The files are
available on the eMDR website,
https://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/
PostmarketRequirements/ReportingAdverseEvents/ucm127951.htm

This guide is divided into two sections: (a) the eMDR Overview section provides general
information on the project and (b) the technical section provides technical information and
implementation details.

Section II: eMDR Overview

This section provides an overview of HL7, the ICSR, and CDRH’s electronic reporting initiative.

II.1 Health Level Seven: Standards Development Organization

HL7 is a not-for-profit volunteer organization. Its members all assist in standards development
and include providers, vendors, payers, consultants, government groups, pharmaceutical groups,
and others who have an interest in the development and advancement of clinical and
administrative standards for healthcare. HL7 is one of several Standards Development
Organizations (SDOs) accredited by the American National Standards Institute (ANSI) that
operate in the healthcare arena. Most SDOs produce standards (sometimes called specifications
or protocols) for a specific healthcare domain such as clinical data, pharmacy, medical devices,
imaging, or insurance (claims processing) transactions. HL7’s domain is clinical and
administrative data.

Like all ANSI-accredited SDOs, HL7 adheres to a strict and well-defined set of operating
procedures that ensure consensus, openness, and balance of interest. A frequent misconception
about HL7 is that it develops software. In reality, HL7 develops specifications—the most widely

2
used being a messaging standard that enables disparate healthcare applications to exchange key
sets of clinical and administrative data.

HL7’s mission is to provide messaging standards for the exchange, management, and integration
of data that supports clinical patient care and the management, delivery, and evaluation of
healthcare services. Specifically, the organization works to create flexible, cost-effective
approaches, standards, guidelines, methodologies, and related services for interoperability
between healthcare information systems.

II.2 ICSR: Individual Case Safety Report

The HL7 ICSR message Release 2 (Normative Edition 2016) supports the exchange of data and
other safety reporting requirements between various public health and patient safety
organizations—specifically, reporting of adverse events or product problems associated with the
use of drugs, therapeutic biologics, vaccines, and devices. Currently, work is under way to
expand the scope of the message to support other types of products such as food, dietary
supplements, cosmetics, or veterinary products and services.

The ICSR message is specifically designed to support individual case safety reports and does not
support population-based case reporting for disease surveillance or outbreak events. The message
can support international safety reporting between public health organizations.

This implementation guide refers to portions of the ICSR Release 2 message that capture the
information needed to report a device adverse event.

II.3 FDA Electronic Submissions Gateway (ESG)

eMDR uses the FDA Electronic Submissions Gateway (ESG), an agency-wide entry point for all
electronic submissions, to receive electronic MDRs. The FDA ESG (also referred to as the ESG
or the Gateway):
 Enables the FDA to process regulatory submissions automatically
 Functions as a single point of entry for the receipt and processing of all electronic
submissions in a secure environment that complies with secure messaging standards
 Serves as a conduit, or “highway,” along which submissions travel to reach their final
FDA destination
 Automatically routes submissions to the appropriate FDA Center or Office.

The electronic submission process through the ESG encompasses the receipt, acknowledgment
of receipt (to the sender), routing, and notification (to a receiving FDA Center or Office) of the
delivery of an electronic submission. Incoming submissions are processed as follows:

1. The ESG receives an inbound submission.

2. The ESG sends a Receipt or MDN (Message Delivery Notification) or Acknowledgment
1 to the submitter; Acknowledgment 1 confirms the submission was successfully
received by the ESG.

3
 3. The submission is automatically transferred to CDRH.
4. Acknowledgment 2 is sent by the ESG to indicate the submission reached CDRH.
5. CDRH validates and processes the submission.
6. Acknowledgment 3 is sent by CDRH to indicate the submission is successfully loaded
into the Adverse Event database or note any errors that occurred during validation and
loading. Acknowledgment 3 is provided in two file formats – xml and html-- both contain
the same information. The two formats are provided to accommodate different user
groups.

Inbound Submission (1)

Acknowledgement #1 (2) Centers

Transfer Submission (3)

FDA Gateway
Industry Server
Partners
Acknowledgement #2 (4) Load to eMDR (5)

CDRH

Acknowledgement #3 (6)

Figure 1: Inbound Submission Processing by FDA ESG

Electronic MDR reporters need to register as trading partners with the ESG to transmit
submissions. For further information, visit
http://www.fda.gov/ForIndustry/ElectronicSubmissionsGateway/default.htm. The site contains
an extensive manual to assist in understanding ESG requirements and a contact email address for
questions about the ESG.

II.4 ICSR and eMDR

The parts of the ICSR provided in the CDRH files referenced in this document map to the device
reporting requirement sections of the current MedWatch Form 3500A. The CDRH files include a
“schema” or “file format” to utilize for submission of MDR data as an ICSR message. Reporters
can use the specified format to submit MDR data.

One of the key features of HL7 version 3 is the use of a standard vocabulary as part of the
message. Members of the CDRH ICSR team worked with terminology experts from the National
Cancer Institute Enterprise Vocabulary Service (NCI EVS) to identify the majority of vocabulary
terms for MDRs. These terms will be stored in the NCI Thesaurus—an open-content vocabulary

4
built for interpretation and access by both people and computers. Concepts such as event type
have an alphanumeric code that corresponds to Death, Serious Injury, and Malfunction. The
receiving system then accesses the vocabulary service information—in this case the NCI EVS
(National Cancer Institute Enterprise Vocabulary Services)—to translate it from the code to the
appropriate event type.

Section III: Technical Section

The purpose of this section is to discuss the technical aspects of the ICSR implementation for
CDRH and the eMDR project. This section begins with a brief overview of HL7 version 3, and
then provides an in-depth discussion of the ICSR message, followed by specific implementation
information for eMDR.

III.1 Health Level Seven Version 3

“Level Seven” refers to the highest level of the International Organization for Standards (ISO)
communications model for Open Systems Interconnection (OSI)—the application level. The
application level addresses definition of the data to be exchanged, the timing of the interchange,
and the communication of certain errors to the application. The seventh level supports such
functions as security checks, participant identification, availability checks, exchange mechanism,
negotiations, and most importantly, data exchange structuring.1

HL7 Version 3 is characterized by:

 The use of a formal design methodology that aims to minimize ambiguity within the
contents of the standard
 Development of procedures for specifying messages and implementation guides that
minimize the use of optional elements within messages
 The use of rigorous modeling during the development of specifications to ensure
consistency across the standard, and to enable mapping to and convergence with other
healthcare standards
 The rigorous definition of vocabularies to assure clear communication
 The use of industry standard encoding—XML (Extended Markup Language)—for
representing message instances

There are two important concepts related to version 3 that facilitate understanding how the ICSR
was created. These are the Reference Information Model (RIM) and Common Message Element
Type (CMET).

Reference Information Model (RIM)

All HL7 Version 3 messages draw their content from a common model—the Reference
Information Model (RIM). Having a single model that provides the starting point for data
definition ensures consistency across the body of HL7 models. When the specification for a

1 www.hl7.org

5
particular purpose (e.g., the Individual Case Safety Report) is developed, it is constructed in such
a way that the resulting model is fully consistent with and derived from the Reference
Information Model. The model that is developed, known as a Refined Message Information
Model (RMIM), uses the base classes from the RIM—Act, Act Relationship, Entity, Role—and
draws on the attributes that have been defined for those classes (i.e., ICSR is an RMIM and uses
the base classes from the RIM).

Common Message Element Type (CMET)

HL7 Version 3 goes to great lengths to prevent independent descriptions of the same concept in
different HL7 models. The chief tool to achieve this goal is the use of Common Message
Element Types (CMETs). CMETs are created to model data structures (e.g., patient, service
location, organization) that appear repeatedly in the requirements for messaging. A CMET is
best thought of as a model fragment that is inserted into another model in a manner like how
subroutines are used in computer programming.

For a more detailed explanation of how messages are created in HL7 Version 3, refer to the
following:

 HL7 ICSR Implementation Guide for FDA Adverse Event Reporting (available upon
request from FDA CDRH eMDR Team until published on FDA Website)
 Understanding Version 3: A primer on the HL7 Version 3 Communication Standard.
Alexander Monch Publishing, 2005 (available at https://www.hl7.org/library/bookstore)

III.2 ICSR: Device Implementation

For the purposes of the voluntary eMDR program, the schema supports only those features of the
ICSR R2 that meet the needs of device reporting. The necessary information and files to generate
the current device ICSR message are provided in this package.

Figure 2 provides a simple representation of the ICSR Model. This ICSR has five RMIMs: the
base ICSR, A_Device_Intervention, R_Device, A_Substance_Administration, R_Drug. The
CDRH implementation traverses down the device path ONLY. A_Device_Intervention captures
information about the procedure that associates a patient with a device; R_Device captures
information about the device itself.

6
 Batch
(Transmission)

Message
(Transmission)

Control Act

Message Payload
ICSR Body
(Base ICSR)

Device Related
Substance Procedure
Administration (A_Device_
Intervention)

Device
Drug
(R_Device)

Figure 2: Simple Representation of the ICSR Model

In HL7, trigger events are identified that initiate the process of information exchange. For the
ICSR, three trigger events are supported: send, update, and delete. At this time, the CDRH
implementation will only be using the ICSR “send” notification PORR_TE040001UV01; that is,
report of a device adverse event and/or product problem is ready for transmission to an eligible
receiver. Other trigger events may be used with further development of the model.

III.3 ICSR Message Contents

The ICSR schema is presented as an XML schema. An XML schema is an XML-based
alternative to Document Type Definition (DTD). The schema defines the:
 Valid structure of an XML document; in this case, the valid structure of the ICSR device
implementation
 Elements that can appear in a document
 Attributes and order of elements and child elements
 Number of elements and child elements (one or many)
 Data types for elements and attributes

7
There are three components to the ICSR message transaction2—transmission wrapper, control act
wrapper, and message payload.

Transmission

Control Act

Message
Payload

Figure 3: Components of ICSR Message Transaction

These transaction components can be further described as follows:

Transmission Wrapper
The transmission wrapper contains information that relates directly to the transmission from
sender to receiver. This is information that would traditionally be captured in a “message header”
(e.g., date of message transmission and message ID).

ICSR Transmission Wrapper

For the CDRH ICSR implementation, the transmission wrapper contains everything in the
schema from the beginning of the file until the tag <controlActProcess>. Note that due to the
hierarchical nature of an XML instance, the transmission wrapper comes before and after the
contents of the control act wrapper and the payload and thus encompasses the whole
message.

Control Act Wrapper

The control act wrapper contains administrative-type information that directly relates to the
trigger event. The trigger event for the CDRH implementation at this time would only include
the send event. The control act wrapper contains details for the message such as who, when,
where, and why; for example, date of the report (MedWatch 3500A Block B4), U/F or Importer
(MedWatch 3500A Block F1), etc.

ICSR Control Act Wrapper

For the CDRH ICSR implementation, the Control Act wrapper would comprise everything in
the schema until the tag <investigationEvent>. Once again, due to the hierarchical nature of
an XML instance, the control act wrapper comes both before and after the contents of the
payload, so in effect it includes everything between <controlActProcess> and
</controlActProcess>.

2 See CDRH ICSR Files for more details

Con170227.xsd—unpopulated message transaction
mappingInstance.xml—sample message

8
Message Payload
The message payload contains the actual adverse event message, and for medical devices, the
specifics of device adverse event information.

ICSR Message Payload

For the CDRH ICSR implementation, the Message Payload would comprise everything
in the schema between tags <investigationEvent> and </investigationEvent>.

III.4 Vocabulary
The HL7 Version 3 specification uses vocabularies to ensure clear communication across
disparate systems. In each HL7 model, including the ICSR, a vocabulary domain specifies the set
of all the concepts that can be taken as valid values in an instance of a particular field or
attribute. The coded values are identified in the HL7 message by an alphanumeric code and an
object identifier coding system. An Object ID (OID) is a way to uniquely identify an object and
is a managed hierarchy that starts with the International Standards Organization (ISO) and
International Telecommunications Union (ITU). ISO and ITU delegate OID management to
organizations such as NCI and FDA by assigning them OID numbers. OIDs are intended to be
globally unique. They are formed by taking a unique string and adding additional digits in a
unique fashion.

This vocabulary provides unique identification of the concept that the code represents. In
addition, they provide capability for the receiving system to convert those codes into meaningful
terms to be stored in the receiving database or IT system.

CDRH ICSR Vocabulary

The CDRH ICSR implementation uses two vocabulary domains: the NCI open-source Thesaurus
and an FDA vocabulary domain. Both follow HL7 vocabulary requirements. You can identify
the different vocabulary domains by noting the unique OID for each domain.

Table 1: Vocabulary Domains for CDRH ICSR Implementation

Vocabulary Domain OID Code Set Location

NCI Thesaurus 2.16.840.1.113883.3.26.1.1 For eMDR – See CDRH
ICSR files:
HL7Medwatch.xls file,
Vocabulary worksheet
FDA 2.16.840.1.113883.3.24 For eMDR– See CDRH
ICSR files:
HL7Medwatch.xls file,
Vocabulary worksheet

Many of the concepts for the CDRH ICSR vocabulary come from the NCI Thesaurus. NCI
Thesaurus assigns a unique concept ID to every item it stores. The snippet below from CDHR
ICSR File illustrates how codes are used in the xml message:

9
 <code code="C25208" codeSystem="2.16.840.1.113883.3.26.1.1"
codeSystemName="Weight"/>
<value xsi:type="PQ" value="100" unit="lb" />

code – The actual alphanumeric value that is used to specify the concept or attribute; i.e.,
in this case, weight
codeSystem – Specifies the vocabulary domain. Note the NCI OID, which indicates this
is the NCI domain.
codeSystemName – Descriptive name of the actual attribute or concept being defined in
this snippet
value – The actual value that is associated with the attribute weight

The value attribute is optional. In some cases, the message contains a standard name for an
attribute (e.g., administrativeGenderCode is the standard attribute for gender or sex). Since there
is no requirement for a special code to indicate sex, the code C20197 specifies the value for sex
(in this case “male”), and there is no need for a value attribute.

<administrativeGenderCode code="C20197" codeSystem="2.16.840.1.113883.3.26.1.1"

codeSystemName="Sex" />

There are two code sets that will not use the NCI Thesaurus OID because they are maintained by
FDA. These are the Manufacturer and User Facility Report ID numbers. Temporarily, we have
assigned the FDA OID to these numbers. The example below illustrates how to value report
number in the ICSR.

<id root="2.16.840.1.113883.3.24" extension="5555555555-2005-0001"

assigningAuthorityName="FDA" />
ID root – FDA OID
extension – Manufacturer and/or user facility report number
assigningAuthorityName – Specify FDA

The CDRH ICSR R2 file 3500A_Sample_HL7_Submission.xml provides a variety of coding

examples. Comments have been inserted into the file to assist you in code assignment. In
general, codes are used to indicate a particular concept (e.g., C53272 is the code for Operator of
Device). Codes also identify values associated with those concepts (e.g., C51804: Audiologist is
an allowable value for operator of the device). Certain concepts do not need a code because HL7
has already identified the concept and hence made accommodations for it in the schema; then
you will not need to assign a code.

As specified in Table 1, the Vocabulary worksheet in the HL7Medwatch.xls file contains a list
of all value sets for the ICSR implementation and for populating an MDR using the ICSR
format. The columns in the spreadsheet contain the 3500A fields (i.e MedWatch Form 3500A
(2/19) Form Approved: OMB No 0910-0291, expires 11/30/2021), label for the term, the
assigned NCI Code, NCI definition, and FDA definition (if available).

In the future, ICSR terms stored in the NCI Thesaurus will be accessible at the National Cancer
Institute Thesaurus Web site via a browser or Application Programming Interface (API)

10
application. NCI staff has created an NCI Thesaurus User Guide for ICSR to assist programmers
in accessing and downloading the codes.3

Refer to https://evs.nci.nih.gov/ftp1/FDA/CDRH/About.html for more information on CDRH

Terminology Files.

III.5 Data Types4

In HL7 version 3, data types define the meaning or semantics of the values that can be assigned
to the attribute. They are not the atomic data types familiar to database and software developers.
Instead, HL7 data types can encompass complex notions such as postal address, clinical concept,
and order frequency. For more information about data types, see the HL7 Individual Case Safety
Report (ICSR) Implementation Guide: FDA Adverse Event Reporting.

III.6 How to Create an MDR as an HL7 ICSR XML File

There are several possible ways to create an MDR as an HL7 ICSR XML message. Below are
some ways among several that are possible.

XSLT (eXtensible Stylesheet Language Transformation)

 XSLT uses XSL (eXtensible Stylesheet Language) and Xpath. Xpath is a query
language for finding information in an XML document; path expressions are used
to navigate XML documents.
 Create an XML file based on your database tables.
 Use XSLT to transform it to an XML - HL7 message.
 Validate it against the schema.

Inject Data into Template

 Start with a “blank” instanceMapping.xml file by removing the data (not the
meta-data) from the file. This will leave you with an XML-HL7 message with
place holders for your data.
 Create a program that opens your blank instance.
 Run SQL statements against your database to retrieve data.

3 See CDRH ICSR

Files for more details refer to:
https://evs.nci.nih.gov/ftp1/FDA/CDRH/About.html

4 See CDRH ICSR Files for more details:

Worksheet 3500A_HL7 of the HL7Medwatch.xls file—Data types and field length limitations are
specified for each Medwatch 3500A. When a field requires a vocabulary term, it is noted as such.
Datatypes.xsd, Datatypes_base.xsd—Common files used to support datatype structures; schema file that
defines the representation of HL7 V3 data types in XML; includes Datatypes-base.xsd

11
  Use XPath to figure out where in the instance the data should be inserted.
 Insert this data into your blank instance.
NOTE: The XPath has been defined to receive specific data. If you have
information that does not conform to a specific field, do NOT add this
information to any required field or the submission may fail.

Create the Message from Scratch

 Programmatically create a new XML file to walk the message structure, query the
background database, and create an XML instance.
 Create a program that opens your new XML file.
 Run SQL statements against your database to retrieve data.
 Use XPath to figure out where in the instance the data should be inserted.
 Insert your data into the instance.

III.7 How to Validate Your ICSR Message

CDRH’s eMDR system validates incoming eMDR xml files for conformance with the HL7
ICSR schema. Any electronic MDR that fails validation will not be processed and an appropriate
message will be sent to the user via Acknowledgment 3. It is recommended that firms planning
on generating HL7 compliant files from their systems validate their XML files for HL7 ICSR
conformance prior to submission using XMLSpy for example. (Note: FDA does not endorse any
specific product or vendor tool)

12
Glossary
API - Application Programming Interface
CDRH – Center for Devices and Radiological Health
CFN – Central File Number
CMET – Common Message Element Type
DTD – Document Type Definition
ESG – FDA Electronic Submissions Gateway
eMDR – electronic Medical Device Reporting
FDA – Food and Drug Administration
FEI – Facility Establishment Identifier
HL7 – Health Level Seven
ICSR – Individual Case Safety Report
ICSR Release 1 – HL7 Normative Edition 2005
ICSR Release 2 – HL7 Normative Edition 2007
ISO – International Standards Organization
ITU – International Telecommunications Union
MDR – Medical Device adverse event Report
MDN – Message Delivery Notice
NCI – National Cancer Institute
NCI EVS – National Cancer Institute Enterprise Vocabulary Service
OID – Object Identifier Code System
OSI – Open Systems Interconnection
RIM – Refined Information Model
RMIM – Refined Message Information Model
SDO – Standards Development Organization
U/F – User Facility
XML – eXtensible Markup Language
XSLT – eXtensible Stylesheet Transformation

13
Hyperlinks
eSubmitter – http://www.fda.gov/ForIndustry/FDAeSubmitter/default.htm
ESG (FDA Gateway) –
http://www.fda.gov/ForIndustry/ElectronicSubmissionsGateway/default.htm
HL7 – http://www.Hl7.org
FDA Data Standards Council http://www.fda.gov/ForIndustry/DataStandards/default.htm
(resources for HL7 messages used by FDA)
CDRH Terminology Files - https://evs.nci.nih.gov/ftp1/FDA/CDRH/About.html

14
Frequently Asked Questions
FDA Electronic Submissions Gateway (ESG)

How is the eMDR project related to the ESG?

eMDR submissions need to use the FDA ESG. In order to use the FDA ESG, you must
purchase a digital certificate and register as a trading partner with FDA. Once registered,
you can submit electronic MDRs via the ESG. For more information, please visit
http://www.fda.gov/ForIndustry/ElectronicSubmissionsGateway/default.htm.

How will my submissions reach CDRH?

Electronic MDRs will be routed from the ESG to CDRH. Once in CDRH, the eMDR
software will load your submission into the appropriate database.

How do I know if my submission reached CDRH?

You will receive three acknowledgments when you submit your MDR electronically.
Refer to Section II.3, Figure 1: Inbound Submission Processing by FDA ESG.
Acknowledgment 1 (also referred to as Receipt or MDN) – confirms the submission was
received by the ESG.
Acknowledgment 2 – sent by the ESG and indicates the submission reached CDRH.

Acknowledgment 3 – sent by CDRH and indicates your submission is successfully

loaded or notifies you of any errors that occurred during validation and loading. Please
note that Acknowledgment 3 is provided in two file formats – xml and html-- both
contain the same information. The two formats accommodate different user groups.
For those reporters using a B2B account (i.e. a gateway to gateway connection) using
AS2, you should not rely on the "Content-Type" header for determining how the
acknowledgments are processed. Acknowledgements should be processed based on the
file extension and actual content, and your systems should be programmed accordingly.

What happens when Acknowledgment 3 notifies us of errors in our submissions?

If you submit an electronic MDR individually (not as part of a batch), and you get an
error message in Acknowledgment 3, please correct the errors and resend the submission.
When you resubmit the MDR, you will get another set of acknowledgments (Ack1, Ack2
and Ack3).

If you submit an electronic MDR as part of a batch (one XML file containing one or
more reports), the batch file is processed. If the batch file fails the HL7 ICSR validation,
the individual report(s) will be rejected with the following message:

Report Number: 5555555-2008-55551

Report Number: 5555555-2008-55552
Report Number: 5555555-2008-55555

15
 error_message: This group of submissions could not be processed because at least 1
submission failed HL7 validation. Report numbers that could be extracted are displayed
above. The following message is the first error that was encountered: Element <badtag>
is not allowed under element <message>.

Please investigate the listed report numbers, fix the validation error and resubmit the
failed MDRs ONLY. Do not resubmit the entire original batch.

When you resubmit the failed MDR(s), you will receive another set of acknowledgments
(Ack1, Ack2 and Ack3). If the failed MDR reports pass the HL7 validation step and fail
further validation checks, Acknowledgment 3 will indicate the status of each report as
loaded successfully or failed to load. Please correct the errors for the failed reports and
resubmit the FAILED reports ONLY. Do not resubmit the entire original batch. When
you resubmit, you will get another set of acknowledgments (Ack1, Ack2 and Ack3).

NOTE: To view sample Ack 2 and Ack 3 notifications in html or xml format, please
refer to the ACK Samples folder located in the Implementation Package shown below:
Implementation Package/eMDR_HL7_ICSR_R2/ACK Examples

What is the time frame to receive these acknowledgments?

You should receive your acknowledgments quickly after your submission, unless the
ESG is down for maintenance. For the ESG status, please check the ESG Website
https://www.fda.gov/forindustry/electronicsubmissionsgateway/aboutesg/
ucm367545.htm.

Does the size of my submission matter?

Delivery and processing time is dependent upon the overall size of your submission;
larger submissions will take longer to be delivered and processed.
Is there a recommended time of day to send submissions?
Submissions can be transmitted at any time via the ESG. Please refer to
http://www.fda.gov/ForIndustry/ElectronicSubmissionsGateway/default.htm for
information on maintenance and down-times.

What about scheduled maintenance and system down-times?

The various systems used to process electronic MDRs are independent of each other with
regards to scheduled maintenance and down-times (please refer to Section II.3, Figure 1:
Inbound Submission Processing by FDA ESG). The system that is down determines what
happens to your submission.
The ESG is down – If the ESG is down, acknowledgments 1 and 2 will be delayed. Your
submission will not able to reach CDRH for processing via the eMDR system. For more
information on ESG maintenance and down-time, please refer to
https://www.fda.gov/forindustry/electronicsubmissionsgateway/aboutesg/
ucm367545.htm.

16
 eMDR system is down – If the eMDR system is down, acknowledgment 3 will be
delayed. If the eMDR system is down, but the ESG is functional, your submission will be
routed to CDRH, and you will receive acknowledgments 1 and 2. For scheduled
maintenance and down-times for the eMDR system, please visit
https://www.fda.gov/forindustry/electronicsubmissionsgateway/aboutesg/
ucm367545.htm. Unscheduled down-times will be announced via the website. Please
visit the website and subscribe to receive updates so you get notified in a timely fashion.

Are there any formatting requirements for filenames submitted via eMDR?
Please make sure filenames do not contain periods except to indicate the file extension.
Due to the way filenames are read, once a period is encountered, the rest of the filename
is considered the file extension.

For example, a filename such as “eMDRSub.mission.xml” will be read as filename

“eMDRSub.missionxml.” This will result in our system not being able to open and read
the file properly, so please only include periods in a filename to indicate file extensions.

Will Requests for Additional Information from CDRH come to us via the ESG,
electronically?
No, at this time the ESG is not set up to handle outgoing requests. You will receive any
request for additional information by mail in keeping with our current practice.

Who do I contact for additional questions regarding the ESG?

For questions regarding registration, set up, or policy, please write to [email protected].

Message Content

How are batch submissions different from individual MDR submissions?

The difference between a batch submission and an individual submission is that the batch
submission, which contains one message header, can contain one or more reports for a
given facility. The individual submission contains one message header and only one
report for a given facility. Please refer to the FAQ above (under FDA Electronic
Submission Gateway) on how batch submission errors are handled.

How do I submit batch submissions electronically?

Batch submissions in eMDR contain one message header with multiple reports. All the
reports in a batch must correspond to one Central File Number (CFN) or Facility
Establishment Identifier (FEI) number. You cannot submit a batch submission consisting
of reports from multiple reporting sites, each with a different CFN/FEI number.

Batch submissions are submitted the same way as individual submissions and are
identified with a batchID. For batchID, use the CFN/FEI number concatenated with 24-

17
 hour timestamp (yyyymmddhh24miss). For example: CFN = 6666666 Date- 11/14/2006,
Time 18:07:25
batch ID = 6666666-20061114180725

Warning: You must enter a valid CFN or FEI number or your report will be rejected.
Please do not send a report number starting with "6666666-…"

There is an element called <batchTotalNumber> that is an integer count of the total

number of reports within the batch. For example, <batchTotalNumber value=”4”/>
means there are four reports in a batch. Each individual report would be submitted as
<message> in the XML submission.

<!-- populate batchID under 'extension'  -->

  <id root="1.1" extension="batchID here" assigningAuthorityName="MessageSender" />
  <creationTime value="20050101" /> <!-- batch creation  -->
  <responseModeCode />
  <interactionId />
  <batchTotalNumber value="4" />
<receiver>
 

Do I need to indicate each report in a batch with an identifier? If yes, how do I do that?
Yes, you need to indicate each individual report in a batch with a message ID. In the
message, indicate each report in a batch with a numeric using the <id extension> attribute
of the <message> element. The IDs should be numeric starting with 1. If there is more
than one in a batch, make the number sequential.

<message>
<!-- If you are submitting a batch of MDR reports, indicate each report with a messageID below  
-->
  <id extension="1"/>

Can we submit multiple patients or devices per MDR report?

No. The current version of eMDR HL7 ICSR R2, allows only one patient and one device
per MDR report; that is, each message can have only one Section A and one Section D.
New to the 3500A form is the Suspect Product Section C. If adding suspect drug
information, this (ICSR R2) version allows up to 20 drugs per MDR report in Section C.

NOTE: For Initial Reports, you must assign each suspect drug product with a different
Drug Sequence Number (1-20). Also, be sure not to have any gaps with your sequence
numbers. (Example: 3 suspect drug products entered cannot have a drug sequence
number of 1, 2, and 4. It must be 1,2, and 3)."

For supplemental reports, gaps in the drug sequence number are allowed.

If you fail to comply with these requirements, you will not be able to package your
submission."

18
How do we report supplemental/follow-up information?
In the xml document, new and updated information that can be provided as discrete data
elements on the 3500A form should be reported with the appropriate xml tags. For
example, if you would like to add/append/change device problem codes, please do not
include it as part of “originalText” under H10. Instead, include this information in the
document where you would normally provide device problem codes with the appropriate
xml tags attached. Please provide new or updated text narrative under the appropriate
sections of the MedWatch 3500A form.

In addition, indicate that a report is a supplemental/follow-up by choosing the right

vocabulary term. Please provide follow-up number in the field -- <text mediaType="
text/plain"/>1</text> -- as shown below. Lack of a follow-up number will result in the
document being interpreted as duplicate of the initial.

<reasonOf>
<detectedIssueEvent>
<!-- Type of Report, BOX G7 -->
<!-- First code is populated with concept ID for Type of Report, Value is code for Follow Up -->
<code code="C53571" codeSystem="2.16.840.1.113883.3.26.1.1"
codeSystemName="Type_of_Report"/>
<text mediaType="text/plain">1</text>
<value xsi:type="CE" code="C53579" codeSystem="2.16.840.1.113883.3.26.1.1"/>
</detectedIssueEvent>
</reasonOf>
<reasonOf>

How do we ‘blank-out’ something we submitted in an initial report? For example, field D4,
Other Number, was submitted as ‘ABCD’ in the initial report. In the supplement, we want
to ‘remove’ or essentially ‘blank-out’ that value. How do we do that?

Warning: You cannot “blank-out” information that was previously submitted. You can
only update the field with new data. It is imperative to be as accurate as possible when
submitting a report (initial or supplemental). If the field in question is not a required field
for submission and you are unsure as to what information to enter, leave it “blank” or
“null”. (For fields that accept a nullFlavor responses, please refer to the ‘How do I
address null values?’ FAQ section in this document). Once you have obtained the correct
information, you can submit a supplemental report with the correct information.

If you submit an initial report and realize that you want to remove the data from the
report, you will NOT be able to, by submitting a supplemental report and adding a
‘blank’ or ‘null” value to the field. The system will interpret the field as no change from
the initial report, and the data will not be updated for that field. Please use field H10 to
explain the change or indicate the change for the field.

Can I respond to an FDA Request for Additional Information electronically?

19
 Yes. Responses to FDA’s Request for Additional Information can be reported under
Section H10. This includes all discrete data elements. Please note this is different from
how supplemental reports are submitted (refer to question above). You may submit the
letter you received as part of the attachment to the message.

Make sure you use vocabulary code C53579 to indicate the report as a follow-up in
Section G7 and use the <text> attribute to provide follow-up number. In addition, please
use vocabulary code C53587 in Section H2 to indicate the follow-up is a Response to
FDA Request.

Can I submit attachments?

Yes. You must encode attachments using Base64 encoding so that they are compatible
with text. Base64 is an encoding method that converts binary data (zeros and ones) into
ASCII text and vice versa. It was originally devised to make it possible to reliably
transmit data and is one of the methods used by MIME. Base64 divides each three bytes
of the original data into four 6-bit units, which it represents as four 7-bit ASCII
characters. It is typical to use MIME base64 encoding to encode email attachments as
well as binary data in XML files. For example, to encode a PDF:
1. Run a program/method that would convert the PDF file to base-64: PDFInBase64
= convertToBase64("c:\myAttachment.pdf")
2. Insert it into an XML instance after converting to string

<!-- Attachments to the MDR can be embedded below. Please refer to the implementation
materials for information on how to embed a document -->
<attachment>
<id nullFlavor="NA"/>
<text mediaType="text/plain" representation="B64">
cmFtZXdvcmsgMS42Jz4NCjxyZGY6UkRGIHhtbGg==
<reference value="sample_attachment.pdf"/>
</text>
</attachment>

There are several free, base64 encoding utilities and libraries available on the Internet in
a variety of languages and platforms. See worksheet 3500_HL7 in the
HL7Medwatch.xls files in the CDRH ICSR package for more details.

In addition, please note the following about attachments –

All file types are currently accepted.

If you have multiple files with different file types that need to be submitted as
attachments, you have the option to zip all documents and attach it as one zipped
file or attach each individual attachment separately.

Multiple zip files for a single MDR will be accepted only when a special
relationship exists between the different files being sent as attachments – for
example, information that requires a series of linked files to open, such as a main

20
 document with hyperlinks that each need a file of its own; lab-results in different
documents, but that are tied together; lab results and x-rays for the same patient
etc.

Please limit each attachment to 50 MB in size.

The maximum filename length for all attachments is a combined 200 characters.
If there are multiple attachments, they should be zipped together so that the
maximum filename length can be preserved.

NOTE: For High Volume (HV) submitters, please be sure to submit only one
XML file and NOT include any archive files (ex. tar.gz) that the ESG guide says
are okay for multi-file submissions.

How do I submit information from the initial reporter?

Depending on the source of the initial report, you may submit information as follows:
1. User facility or importer report – Include report information by populating the
appropriate fields of the message; i.e., populate all sections of the message
pertaining to MedWatch 3500A Section F.
2. Voluntary report – Submit as an attachment to the message.
3. If you have more than one source report for the event; that is, (1) and (2) as
described above, you may include one report as part of the message and submit
others as an attachment.

How do I address null values?

Every element in the HL7 xml message can have a nullFlavor attribute. However, an
eMDR report must have values for report number, event description (B5), and type of
device populated with the device product code (D2). If these are not valued, the record
will be rejected for entry into eMDR.

Where null values are accepted, we strongly encourage you to please use the following
allowable null values attribute instead of leaving the fields blank. The allowable values
for nullFlavor in eMDR are:

ASKU – asked but unknown

NI – no information; answer could be available, but no information was provided
NA – not applicable; this question does not apply to the situation

However, for code fields such as F10 problem codes, please use actual code values to
indicate ‘unknown’ whenever possible instead of a null value. For example, if device
problem is not known, please use code 2204 instead of a null value.

21
 Warning: Where null values are accepted, you must enter a null value in the nullFlavor
attribute. If you enter a null value in an attribute other than the nullFlavor attribute, (I.e.
the value attribute) the submission will fail.
Refer to the coreschemas folder in the implementation package to determine which fields
have the nullFlavor attribute.

How to use nullFlavor attributes:

Strings:
For fields that require a character string data type (e.g. <name>patient name</name>), you
can indicate a null value as follows:
<name nullFlavor="ASKU"/>

Dates:
For date values, indicate null value as <effectiveTime nullFlavor="NI"/>.

So when you have data for a date field, it looks like this:
<time>
<low value="20060116" />
<high value="20061016" />
</time>
 
And when you do not have data for a date field, it looks like this:
<time>
<low  nullFlavor="NI"/>
<high  nullFlavor="NI"/>
</time>
 
There may be a desire to populate the value attribute with a nullFlavor, but this is
incorrect:
<time>
<low value="NI" />
<high value="NI" />
</time>

Boolean:
For Boolean values that need to be indicated as null (e.g. <value xsi:type="BL"
value="false" />), you can indicate null value as follows:
<value xsi:type="BL" nullFlavor="NI" />

Other Boolean values (e.g. <receiver negationInd="false"/>) use nullFlavors in the same
way:
<receiver nullFlavor="NI"/>

22
 Please refer to the earlier FAQ on ‘blanking-out’ or ‘removing’ a value in an initial report
to be sure you understand how null values are interpreted in Supplemental reports.

Can I submit special characters as part of an MDR?

Acceptable special characters are limited by the character set
AMERICAN_AMERICA.WE8MSWIN1252 being used by our database. Some of the
more commonly used characters such as trademark, copyright and registered symbols are
accepted. Please note that there are some special characters such as ampersand (&), less
than (<), greater than (>), single quote ('), and double quote (") that need to be encoded
using the hexadecimal character reference. For example, CompanyA & CompanyB would
need to be CompanyA &amp; CompanyB. We have found a few symbols that are not
accepted e.g. Euro symbol. We are working to come up with a more exhaustive list.

NOTE: The XML file is encoded in UTF-8, but the only special characters allowed are
those included in https://msdn.microsoft.com/en-us/library/cc195054.aspx

How do I submit explanations when I choose “Other” for a field in the 3500A?
You can use <originalText></originalText> to submit explanations for other. This example
is taken from CDRH ICSR R2 file 3500A_Sample_HL7_Submission.xml. It shows the
use of “Other” with an explanation for Section H7.
<deviceObservation>
- <!-- If Remedial Action Initiated, Check Type, BOX H7 -->
- <!-- Code is populated with Concept ID for Type_of_Remedial_Action, Value is code for
Other   -->
<code code="C53603" codeSystem="2.16.840.1.113883.3.26.1.1"
codeSystemName="Type_of_Remedial_Action" />
- <value xsi:type="CE" code="C17649" codeSystem="2.16.840.1.113883.3.26.1.1">
- <!-- populate below if OTHER was chosen for H7, text to explain OTHER   -->
  <originalText>Something else entirely different happened</originalText>
</value>
  </deviceObservation>

We normally submit two addresses under G1—Contact Office (name and address) and
MDR contact address and manufacturing site address. How can we do that in the HL7
ICSR message?
The current ICSR release being implemented allows only ONE address under G1.
However, we have implemented a workaround for the near term, which allows two
addresses to be submitted—both the MDR contact name and address and the
manufacturing site address.

Repeat the <contactParty/> block in the message twice. Submit MDR contact information
as the first address or address one and manufacturing site information as the second
address or address two. Please refer to the mappingInstance.xml document to see an
example.

23
 Note that the order of the addresses determines which address gets loaded to which
location in the database, so it is extremely important to submit the correct address in the
order noted above.

If our system is down, can we submit by paper as a backup?

On Feb. 13, 2014, the FDA published a final rule on Electronic Medical Device
Reporting (eMDR) that requires manufacturers and importers to submit MDRs to the
FDA in an electronic format that the FDA can process, review, and archive.
Manufacturers and importers had until Aug. 13, 2015 to begin submitting all MDR
reports electronically. No paper reports are being accepted from manufacturers or
importers at this time.

If your high-volume system is down, the FDA recommends that you create submissions
via the CDRH’s electronic submission tool, eSubmitter. Once you have successfully
created and packaged your submission with the eSubmitter software, you can use your
ESG WebTrader account as a backup and submit your submissions to the FDA.

Electronically submitted adverse event reports do not have all the fields found in the 3500A
form able to be mapped. How should we send information that is not able to be mapped to
a 3500A field?
Correct. Some fields such as G5’s check boxes for combination product, pre-1938, and
OTC product are not available for mapping. If you would like to indicate this information
or any information that is not mapped, please use section H10 (manufacture narrative) to
indicate this information.

Testing Process

What are the steps involved in testing to submit MDRs electronically?

Before you begin testing, you need to have two things in place –
(1) A test FDA ESG account. Visit
https://www.fda.gov/ForIndustry/ElectronicSubmissionsGateway/CreateanESGA
ccount/default.htm for information.
(2) Ability to generate electronic MDRs. You may generate HL7 compliant
MDRs via custom programming or use the eSubmitter program.

We recommend you do some internal testing by sending a few test submissions through
to make sure you receive all three acknowledgments. Once your internal testing is
complete, you are ready to begin formal testing with CDRH eMDR Team.

Formal testing is an interactive process where you work closely with the eMDR team to
make sure your electronic submissions load accurately into our test systems. It is critical
that you inform the eMDR Team before you begin testing. Please send an email to

24
 [email protected] to schedule testing. Once testing is complete, the eMDR Team will
inform the ESG team to provide you with a production ESG account. All submissions
sent using the production ESG account will be loaded to production MAUDE.

Can we send test submissions through the ESG?

Yes, you can. Please notify the eMDR team via an email to [email protected]. A pdf
copy of the test 3500A form needs to be sent to the eMDR email address, so we can
verify your rest report in our test systems.

What data can we use for testing?

All test reports are loaded to our test database. This will not be released to the public at
any time. You can submit ‘made-up’ data for testing or use data from a prior 3500A. To
ensure that your report does not get rejected because a duplicate report is present in our
system with the same report number, please use a leading 7 in your sequence number.
Example -- CFN-YEAR-70001 or FEI Number-YEAR-70001.

How many reports are required for testing?

The purpose of testing is to catch any issues early on, so once you transition to electronic
reporting there are no major problems. Testing will continue until all/any issues are
resolved satisfactorily. Issues can arise as a result of improper formatting, validation
failures, etc.

If you are using the HL7 ICSR high volume option, please make sure you “validate”
your submission against the HL7 ICSR R2 schema (Con170227.xsd file in the
eMDRHL7 implementation package coreschema folder) before submitting it to CDRH.
This file is also available at http://www.accessdata.fda.gov/eMDR/Impl_files/
Con170227.xsd. Files that do not validate cannot be processed. Refer to Section III.7
for more information on validation.

Below are five types of reports that are requested for testing. If a particular report does
not apply to your situation, please discuss with an eMDR team member.
(1) A complete initial manufacturer MDR (fill every manufacturer report field)
(2) A supplemental MDR to submission #1
(3) An initial MDR with an attachment. This test is not required for firms with AS2
software that does not support attachments
(4) A complete initial MDR user facility or importer report (F2 UF/importer report
number filled, but sections G and H empty). This test is not required for firms that
will never submit a user facility or importer report.
(5) A batch submission that includes more than one MDR in a single XML file. This
test is not required for firms with AS2 software that does not support batch
submissions

25
 If you have additional scenarios of reports that you submit and would like to submit them
as a test, please contact an eMDR team member to set up testing.

Test submissions are only stored for two weeks in the pre-production environment, so
you will not be able to use older submissions from your initial testing.

Once testing is complete how do we move to production?

Once testing is completed, the eMDR Team will notify the FDA ESG team to provide
you with a production account. Establish your production gateway account and then
begin production submissions. Please make sure you use the production gateway account
for your production submissions. If you use the test gateway account, the report will load
to test systems.

Does the eMDR Team need to be notified when we move to production?

Yes. Please send an email to [email protected] to inform the eMDR team when you
send your first production submission. Please email a pdf copy of your electronic
production MDR. The eMDR team will verify that your report loaded accurately into
production systems. You are then on your way to submit your ‘real’ MDRs
electronically.

Other Questions

What about future updates to the ICSR?

The current CDRH implementation is based on ICSR R2 (Release 2). As of 7/5/2018,
ICSR R1 is no longer be accepted. CDRH plans to eventually adopt future releases of
ICSR as they become available. When the time is appropriate for CDRH to adopt a future
release, sufficient notice and time will be provided for migration.
Please note that any technical solution implemented as part of your participation in
eMDR using Release 2 needs to be flexible enough to adapt to future releases.

Do I need to indicate the Release of ICSR in the message? If yes, how do I do that?
Yes, you need to indicate the Release of ICSR you are submitting.
In the message, you indicate the appropriate release at the beginning, using the
<versionCode> element as shown below.

<versionCode code="V3NORMED_2016"/>

V3NORMED indicates HL7 Version 3, Normative Edition

V3NORMED_2016 indicates the ICSR R2 version

26
 NOTE: The FDA no longer accepts ICSR R1 “V3NORMED_2005” and will only
accept the ICSR R2 version.

How many characters can we use to submit country codes?

Current CDRH implementation will support the following standard versions of country
codes:
FIPS 5 (NIST standard) – two characters
GENC3 – three characters

A document mapping the FIPS-5/NIST two-character and GENC3 character codes is

provided in the HL7Medwatch.xls document for your use.

How do we get updates on the eMDR Program, system maintenance and down-times?
eMDR system status information will be posted on the eMDR website at
https://www.fda.gov/medical-devices/mandatory-reporting-requirements-manufacturers-
importers-and-device-user-facilities/emdr-electronic-medical-device-reporting

To receive updates on the eMDR System, click on “Subscribe to Email Updates”.

Who should we go to for questions?

For general questions on eMDR, please send an email to [email protected].

For all ESG questions, please contact the ESG staff as indicated on their Web site
http://www.fda.gov/ForIndustry/ElectronicSubmissionsGateway/default.htm.

What is a Unique Device Identifier (UDI) Number?

As defined in 21 CFR 801.3, an UDI on a device label or package is composed of two parts:
1. Device Identifier (DI)—a mandatory, fixed portion of a UDI that identifies (1) the labeler
and (2) the specific version or model of a device;
and

27
 2. Production Identifier(s) (PI)—a conditional, variable portion of a UDI. If any of the
following is included in the label of a device, it must also be included in the PI.
Any identifiers other than the five listed below are outside the scope of FDA regulated
UDI. Each of these five identifiers may also be called a “PI.”
 the lot or batch number within which a device was manufactured;
 the serial number of a specific device;
 the expiration date of a specific device;
 the date a specific device was manufactured;
 for an HCT/P regulated as a device, the distinct identification code required by 21
CFR §1271.290(c).

For more information regarding the format of the UDI, refer to the following Unique
Device Identifier FAQ document located at:
http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/
GuidanceDocuments/UCM410439.pdf

NOTE: Manufacturer and distributor reports should include the DI only. User Facility
reporters who cannot parse the DI out of the complete UDI should include the whole
human-readable UDI.
What is a Drug Sequence Number used for?
A drug sequence number is a numeric value between 1 and 20 that is associated to a specific
suspect drug product. A submission can contain up to 20 suspect drug products per submission.
The drug sequence number is a unique identifier associated to each suspect product so that it can
be used to identify and update any suspect product (via supplemental reports).

NOTE: Your submission will not be processed if one of the following occurs:
 Missing Drug Sequence Number
 A gap in the drug sequence numbers associated with your suspect products pertaining to
an initial report
Example: 3 suspect products added to a submission. The Drug sequence numbers
should be 1, 2, and 3. It cannot be 1, 2, and 4.
 A duplicate drug sequence number within an initial or supplemental report
 A gap in the drug sequence number with respect to all submissions (initial and
supplements)
Example: 2 suspect products added to the initial submission with drug sequence
numbers 1 and 2. A supplemental report containing a new suspect product with a
drug sequence number of 4

Where do I enter Concomitant Medical Products and Therapy Dates for Section C2?
All Concomitant Medical Products and Therapy Dates should be entered in section D10.

28