SOFTWARE - EXPANDED ONLINE VERSION

At the 2007 annual meeting of the Regulatory Affairs Professionals Society (RAPS), the former head of FDA's postmarket management transformation group, Don St. Pierre, updated attendees about the agency's status with regard to electronic medical device reporting (eMDR). Encouraging device manufacturers to begin using electronic reporting systems, St. Pierre quipped, "You can do it now, or you can wait for it to be done to you."

Despite the implication that agency action on eMDRs would be imminent, FDA still does not require companies to file medical device safety reports electronically, and many manufacturers remain in a holding pattern--content to wait for the new reporting regulations to be 'done to them.'

However, it's only a matter of time until the agency makes good on its promise. CDRH is actively working to complete a rules document that will outline dates and requirements for medical device manufacturers to go fully electronic with their adverse-event reports. In short, the time to understand and implement eMDR has arrived.

FDA's Transition

A major force driving FDA to adopt electronic reporting is the sheer volume of reports received by the agency, making electronic reporting a must in order to protect the public welfare.

When Congress enacted the Medical Device Amendments of 1976, it authorized FDA to issue guidelines for reporting adverse events involving medical devices. But between 1976 and 1996, when the agency's requirements for tracking adverse events were finally codified, device reporting was often inconsistent and delayed.¹ Moreover, the agency had no mechanism for tracking reports.

By 2000, FDA was receiving 100,000 paper reports per year. Over the next six years, the volume of reports that the agency received more than doubled to 220,000. In some months, FDA has received more than 20,000 Medwatch form 3500A device reports, each of which must be manually rekeyed into an online database. This method of transferring paper 3500A device reports is both costly and prone to error. For the report sender, manual entry and transmission of paper 3500A forms is also expensive and prone to error--especially when report updates are required.

As volume has increased, more reports have been delayed, filed late, or not filed at all. As a result, it became increasingly clear that in order for the agency to meet its legal obligation to track adverse events pertaining to medical devices, the entire MDR process needed to be overhauled.

In January 2006, FDA convened a working group--the Postmarket Transformation Leadership Team (PTLT)--to address these issues. The team's mandate was to conduct a top-to-bottom review of CDRH and to make organizational and other recommendations that would improve the device center's processes, data analysis, and compliance. The top recommendation in the PTLT summary report was to institute electronic reporting and to make electronic reporting of adverse-event data mandatory.²

From MedWatch to eMDR

Making electronic reporting a reality also creates new challenges. To automate a process, standards and rules must be written, agreed to, and applied (see Table I). The eMDR process included mapping each of the fields on the 3500A device report form to a data field. Moreover, a standard for storing the mapped fields had to be developed.

To accomplish this task, FDA turned to the Health Level 7 organization (HL7; Ann Arbor, MI). HL7 is a not-for-profit group composed of volunteers from industry, government, consultants, and others who have an interest in advancing clinical and administrative standards for healthcare. The group is accredited by the American National Standards Institute as a standards development organization. HL7 does not produce any software, hardware, or policy--it develops specifications. And, in the case of eMDR, these included a messaging standard for the transmission and acknowledgement of individual case safety reports (ICSRs).

Electronic ICSRs are data structures that support the exchange of adverse-event data pertaining to drugs, devices, vaccines, and therapeutic biologics. The structures are versatile, in that different types of adverse events can be transmitted. However, each type of ICSR is governed by very strict rules that control what data can be transmitted, how the data must be ordered and organized, and what type of file format must be used for transmission. The file format used for eMDR is extensible markup language (XML), and the governing documents for XML files are schema files called document type definitions.³

HL7's scope of influence was the format of eMDR transmission, not the mode or method of transmission. In late 2006, FDA opened the electronic submissions gateway (ESG), a centralized conduit for receiving and routing all e-reports being sent to the agency or any of its centers or offices.⁴ The ESG has strict protocols for receiving data, including security, encryption, and transmission guidelines. It is the report sender's responsibility to properly configure the electronic data interchange (EDI) software that it will use to send eMDRs.

In August 2007, with the format for eMDR set and the gateway for receiving reports established, FDA began accepting eMDR reports. To encourage use of eMDRs, FDA published free CDRH electronic submissions software, CeSub, which is designed for low-volume reporters. CeSub enables reporters to input single reports and transmit them to CDRH immediately without the need for EDI software. ⁵

eMDR Use and Acceptance

As outlined above, it has been possible for medical device manufacturers to transmit eMDRs to FDA since August 2007. According to FDA statistics, however, only one company is currently making use of the ESG, and only seven are using the CeSub low-volume submissions tool. The lone high-volume submitter came online in March 2008, accounting for a significant increase in the number of eMDRs received by the agency each month (see Table II).

There are several reasons why device manufacturers have so far failed to make greater use of FDA's new eMDR capabilities. First--and probably most important--is the simple fact that use of the system is not yet required. In 2007, there was speculation that FDA would begin requiring eMDR submissions sometime during 2008. But this timetable has since been pushed back, and now it is unknown when the agency will mandate eMDR submissions.

A second reason that industry has been slow to move toward eMDR submissions has to do with the complexity and uncertainty involved in shifting from traditional paper-based systems. Designing software applications that can create eMDR-approved outputs necessitates a foundation in electronic reporting knowledge as well as a level of comfort with the requisite technologies. Many companies are still unprepared to transition from their paper-based systems to eMDR.

A third reason involves the not-so-small matter of acknowledgements (ACKs) and negative acknowledgements (NAKs), which are cornerstones of all electronic reporting systems. In an automated environment, ACKs and NAKs are essential for proper execution of data transfers, retries, process flow, and error handling. Many systems provide acknowledgements in the form of XML files with specific formats and known element definitions. This makes it very easy to automatically process return messages, since the executing programs know exactly what to look for and where.

For proper functioning, the eMDR system also depends on having a process for handling acknowledgements. It is essential for the sender to know that its transmission has been received and that the transmitted data have been validated. To accomplish this, the current design of the eMDR platform incorporates three levels of acknowledgement, as follows:

It is the format of the third acknowledgement that has slowed software vendors and users from being able to fully transition to eMDR. Instead of a structured XML file, this acknowledgement is an HTML-formatted document (i.e., a Web page) that lists each report submitted by the sender, and advises whether each report loaded properly into the CDRH device report database. Compared with the more structured XML files, HTML files are not easy for computer programs to parse, and they typically require review by the sender. But in the meantime, at this last stage of the process, the absence of an XML-formatted acknowledgement makes it difficult for the report sender to determine immediately whether its eMDR report was accepted or whether it needs to be resubmitted. Fortunately, during recent discussions, CDRH indicated that it is actively developing a standard XML-formatted acknowledgement for all eMDRs that it receives.

As knowledge of FDA's eMDR system proliferates across the medical device industry, and as clarity emerges on the challenge of acknowledgements, a higher level of adoption may be achieved. But driving the majority of medical device companies to adopt the eMDR system will likely take a truly compelling event. Almost certainly, that event will occur when CDRH releases its long-expected rules requiring that manufacturers implement eMDR systems over paper 3500As.

Planning for the Future

Preparing to implement an eMDR system is not complex. A simple decision tree can help organizations determine a course of action (see Figure 1).

Pick a Number. The burden represented by eMDR filings is subjective and generally relative to the size of the organization. If the volume of reports is expected to be low, the company should use FDA's CeSub low-volume submissions platform. Otherwise, the company should prepare to use a full-featured eMDR system.

Pick a Database Platform. Determine whether the company already has a software platform suitable for storing and retrieving complaint information. If not, design one in-house or select a commercially available complaint management system.

Pick a Reporting Platform. Determine whether the company already has a software platform that can generate properly formatted eMDR output. In some cases, software for this purpose may be integrated with commercially available complaint management systems. If no such system is available, design one in-house or choose a commercially available eMDR reporting platform.

Pick a Transmitter. Choose an EDI transmission provider or use in-house facilities.

FDA is available to help with every phase of development. The agency encourages manufacturers and other reporters to use a two-pronged development effort. In this approach, one group prepares formats for the eMDR output files, while the other works on setting up EDI communications.

Ready, Set, Test

After preparations for storing, reporting, and transmitting eMDRs have been completed--and prior to submitting any actual adverse-event reports--FDA requires users to set up a test account. This account is used for testing all phases of the eMDR cycle, including XML file validation, transmission verification, and posttransmission processing of acknowledgements. Instructions for setting up a test account can be downloaded from FDA's ESG Web site at www.fda.gov/esg/account.htm.

Each user of the ESG must submit a nonrepudiation agreement letter. This letter includes the user's actual signature, and acknowledges that a digital certificate may be used as the submitter's electronic signature.

All eMDR data that are transmitted to FDA must be encrypted. Encryption is accomplished through the use of the digital certificate assigned to each user. Thus, digital certificates are used to encrypt data, and they also function as electronic signatures for their assigned users. Digital certificates may be valid for varying durations, but FDA only accepts two-year certificates.

Once the test account has been created, the ESG permits transmission of test files. A reply e-mail detailing the status of the testing is returned after each test. When testing has been completed, the user can begin production and transmission of live eMDRs.

Conclusion

Although CDRH continues to accept paper reports, it is no longer accepting MDRs on CD or DVD without special approval. Once the eMDR acknowledgement challenge has been resolved, and all return messages are in XML format, the countdown to mandatory eMDR submission will begin. For medtech engineers, understanding an e-reporting strategy now will help their companies to avoid a compliance crunch later.

Reference

1. "Medical Devices; Device Tracking; New Orders to Manufacturers" Federal Register 63, no 42 (March 4, 1998): 10638-10640; available from Internet: www.fda.gov/cdrh/modact/fr0304af.html.

2. Report of the Postmarket Transformation Leadership Team: Strengthening FDA's Postmarket Program for Medical Devices (Rockville, MD: Center for Devices and Radiological Health, FDA, 2006); available from Internet: www.fda.gov/cdrh/postmarket/mdpi-report-1106.html.

3. eMDR: Electronic Medical Device Reporting, Health Level Seven (HL7) Individual Case Safety Reporting Files [downloadable zipped files] ( Rockville , MD : Center for Devices and Radiological Health, FDA, 2007 [accessed 8 July 2008]); available from Internet: www.fda.gov/cdrh/emdr/eMDRHL7files.zip.

4. FDA Electronic Submissions Gateway (ESG) [online] (Rockville, MD: Center for Devices and Radiological Health, FDA, 2007 [accessed 8 July 2008]); available from Internet: www.fda.gov/esg.

5. CeSub eSubmitter [online] (Rockville, MD: Center for Devices and Radiological Health, FDA, 2007 [accessed 8 July 2008]); available from Internet: www.fda.gov/cdrh/cesub.

Copyright ©2008 Medical Device & Diagnostic Industry