eMDR Conversion and Implementation - Part II

Note: The views expressed in this article are those of the author and do not necessarily represent those of his/her employer, GxP Lifeline, its editor or MasterControl, Inc.

This is the second installment of a two-part series reviewing the basics of electronic medical device reporting. (See Part I).

This section covers best practices and tips for better submission of reports.

Best Practices for Submitting eMDRs

Best practices for submitting eMDRs are similar to those for paper submissions—the more information in the report, the more complete it will be.

Implementation of an automated submission system is a bit more complex, though there is no shortage of help. The ESG provides a user guide (the same one used for WebTrader) which covers the transmission of files using the AS2 protocol.

And for supplements, we recommend following the instructions found in 21 CFR § 803.56(c), which states that supplemental or follow-up reports should "Include only the new, changed, or corrected information in the appropriate portion(s) of the respective form(s) for reports that cross reference previous reports."

Along with these standard best practices, there are some specific ones to eMDRs. In order to cover them best, I'll discuss each submission method separately:

  • eSubmitter/WebTraderFor submitting electronic reports using eSubmitter and WebTrader it's important to send the correct file to FDA. eSubmitter produces a zip file, which contains the necessary information to process your submission. This file is only produced by using eSubmitter's "packaging" tool. Then, when going to WebTrader to actually send the file to FDA, you'll need to know where that packaged file is in order to upload it into WebTrader. Sending any other type of file will result in a notice that the submission failed validation, then you'll need to try to submit it again (possibly delaying the "real" submission being sent and passing validation).
    Naming conventions are important for more complete and consistent tracking by reporters. Once the submission is sent to the FDA ESG, the file name you provided is changed to a unique identifier called a core-id, but all acknowledgements sent regarding the submission to WebTrader (though they reference a core-id) are associated with the file name you give the report in the WebTrader interface. So it's important that the names of the files submitted to FDA are in a convention that suits the reporter best and that can be used to locate the report and any acknowledgements for the report later.

  • Direct/Automated SubmissionIf the method of submission does not include eSubmitter and WebTrader, there are other items of note that should be considered as best practices for submitting in the direct/automated fashion. This method allows for the submission of a single report much like eSubmitter/WebTrader, but it also allows the submission of multiple reports in a single ICSR xml file. If submitting a batch of submissions in one file is implemented in a system, it's best that the batches are broken up in reports of 500-1000 reports per submission. The reason for this isn't performance driven, but rather ensuring the number of reports per batch doesn't hold other reporters up in line for their submissions to be processed.A good practice for automated submitting is to validate the ICSR xml message against the schema for Health Level Seven (HL7) v3 Individual Case Safety Report (ICSR) release 1 prior to submitting to FDA. It's often the case that implementations of an automated submitting solution validates data elements (e.g, ensuring dates are valid, character field lengths are with the maximum allowed, etc). If they are not valid, FDA provides an acknowledgement noting that a submission failed processing due to a data issue and that issue is described. However, there are cases in which the data is not the issue but rather the xml file itself isn't structured properly. If the xml itself is at fault, FDA isn't able to read the xml file since it's not considered valid and the acknowledgement sent may not be helpful in determining why the submission failed. So along with data validation, the message should also be validated against the schema before it is sent to FDA.
    Without eSubmitter to package the submission, users of this method must generate their own electronic ICSR message in xml format. Even with extensive testing, constructing an xml message in required format does not always occur, despite validating against the schema or going through strict data validation. There are cases in which data can be submitted to FDA unintentionally or incorrectly with the incorrect use of "nullFlavors." The concept of a nullFlavor is to provide in the ICSR message a way of providing blank data and the reason for the data being blank. It has been found in testing that some reporters do not use nullFlavors correctly and instead provide nullFlavor values in actual data fields, thereby adding values to the report that was otherwise not intended to be there. For this reason, it's important to read the technical files FDA provides regarding nullFlavors to ensure that only the data meant to be present in a report is added to FDA's database.

Implementation Challenges and Solutions

When discussing implementation, it's best to separate out the two methods of submission:

  • eSubmitter/WebTrader
    Like many regulatory procedures, documentation is key. eSubmitter can produce three files for a submission, the eSubmitter xml file format, the pdf facsimile of the 3500A, and the final zip file for submission to FDA. It's up to the reporter to determine what should be stored as part of the regulatory file for a report. WebTrader also produces files, specifically the receipt and acknowledgements sent by FDA to the WebTrader account. These files should be kept in the possession of the reporter as part of regulatory file since the information contained in them represents when the report was submitted and whether or not it was accepted by FDA. Do not use WebTrader as the location to store these acknowledgements since FDA could (and has) removed files from WebTrader accounts, after fair warning.

  • Direct/Automated Submission:
    Much like for WebTrader, the receipt and acknowledgements should be stored and associated with the report in some way, as they serve as submission documentation and FDA acceptance. Unlike WebTrader, there may be cases where reports and their statuses are unknown due to technical issues involving the processing of acknowledgements by a reporter's system or the acknowledgements not being received by the reporter's system. For this reason, the key requirement that should be in place in any automated system is the concept of intervention. There should always be a way to manually intervene in the report's submission process.

Implementation Tools and Strategies

Whatever method of submission a reporter chooses (I will mention again that both methods are open to all reporters regardless of the volume of submissions) there are a variety of tools to help him/her get started.

  • eSubmitter/WebTrader:To become accustomed to eSubmitter, there are several video tutorials available on the FDA eSubmitter website. These tutorials cover the basic operation of the application. Though the videos are not specific to creating MDRs, they were created to show how it is best to use eSubmitter. Additionally, eSubmitter has a user guide which also helps with basic operations and is a great resource when you might not be clear on how to use a feature.
    WebTrader also has a user guide found on the ESG website which can explain much of the interface and functionality.

  • Direct/Automated Submission:Implementation of an automated submission system is a bit more complex, though there is no shortage of help. The ESG provides a user guide (the same one used for WebTrader) which covers the transmission of files using the AS2 protocol.
    For creation of the message which will be used to send the report to CDRH, there are technical files on the eMDR website which contain xml schemas, implementation/creation instructions, mapping documents (mapping the elements of the xml to a 3500A) and even an example HL7 v3 ICSR r1 xml file. The example file covers every element though—if specific examples are desired—eSubmitter can help. When eSubmitter packages a file, it creates a zip file which contains an HL7 v3 ICSR r1 xml (named ICSR_HL7.mxl) which can then be used to model an automatically generated message from a reporter's automated system. So a reporter could use eSubmitter to construct an MDR to see what it should look like in order to submit to FDA. The only difference between an eSubmitter generated file and an automated file developed by the reporter is that eSubmitter adds an extra element (<softwareName>) which should be removed in an automated system's generated message.

How to Set Up and Test Your System

Once a method of submission has been chosen, it's time to test the method in order to be approved for a production ESG account. For this, CDRH has an excellent testing environment that mimics the eMDR processing system during production. The test system is great for submitting reports in various configurations to ensure that the way a submission is formatted, created, and sent works prior to submitting to the production environment.

Even after a production account is obtained the test system is still available to submitters and is a great way to test submissions when there is a change in the way a reporter will be submitting. Changes could span from something as simple as deciding to add attachments to changing to a new automated method of submitting. Whatever the change, if there is a need to ensure that a submission process will work, the test system is available.


Whichever method of submission is chosen, each has its own points of interest which need to be managed by the reporter. Just remember that whatever steps are taken to manage electronic submissions, reporters need to ensure that they are in compliance with all applicable regulations. With the use of an electronic submission system, compliance in regards to the submission process of electronic MDRs will be faster and more manageable.

Eugene Reilly is a public health analyst in FDA's Center for Devices and Radiological Health (CDRH) Office of Surveillance and Biometrics and works on the systems (and the policies that drive them) that process, display, and analyze medical device adverse event information. Additionally, he also maintains the CDRH Event and Evaluation Codes used in MDRs.

Eugene began his career with FDA in the Office of In Vitro Diagnostic Device Evaluation and Safety as a clinical reviewer and compliance officer. Prior to and during his time with FDA, he is a programmer focusing on XML, Python, and Java for databases, web based applications, and computer graphics. He may be reached at (301)796-6156 or Eugene.Reilly@fda.hhs.gov.