MD+DI Online is part of the Informa Markets Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Electronic Medical Device Reporting

Technologies available today are enabling medtech executives to plan for the regulatory future.

INFORMATION TECHNOLOGIES

At last year's 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 actually makes good on its promise of action. FDA's Center for Devices and Radiological Health (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 for implementing 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.1 Moreover, the agency had no mechanism for tracking reports.

By the year 2000, FDA was receiving 100,000 paper reports per year. Over the next six years, the volume of reports received by the agency 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 is prone to error as well—especially when report updates are required.

As volume has increased, more and more reports have been delayed, filed late, or not filed at all. As a result, it has become 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 number one recommendation in the PTLT summary report was to institute electronic reporting and to make electronic reporting of adverse-event data mandatory.2

From MedWatch to eMDR

Making electronic reporting a reality also creates new challenges. In order 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.

Table I. (click to enlarge) Main classes of software belonging to an eMDR system, listing key functions and subsets of each class.

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 (ANSI) as a standards development organization. HL7 does not produce any software, hardware, or policy—it develops specifications (in the same manner as the International Conference on Harmonisation (ICH), which developed the E2B standard for drug safety reports). 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 (DTDs).3

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.4 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.5

eMDR Use and Acceptance

Table II. (click to enlarge) Electronic medical device reports filed with FDA's Center for Devices and Radiological Health since the launch of the eMDR system in August 2007 through May 2008.
Source: FDA.

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 medical 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 not known 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 away from their paper-based systems to an eMDR system.

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 system, such acknowledgements 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.

  • The ESG sends an XML-formatted ACK or NAK that indicates whether the transmission was valid.
  • ESG sends an XML-formatted ACK or NAK to inform the sender that its data have been forwarded to CDRH.
  • CDRH sends an HTML document indicating whether the sender's reports were valid.

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 reports were accepted or need 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

Table I. (click to enlarge) Figure 1. A decision tree to assist manufacturers in determining how to develop an electronic device reporting system.

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 is 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 (CMS).

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 electronic data interchange (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 post-transmission 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 also function as electronic signatures for their assigned users. Digital certificates may be valid for varying durations, but FDA will accept only 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.

Costs, Benefits, Rationale

Converting a system or designing a new system for high-volume eMDR submissions involves startup costs. The total outlay will depend largely on the infrastructure already in place. There is a moderate incremental cost associated with the inclusion of eMDR capabilities while implementing a next-generation complaint management system (CMS). Alternatively, adding eMDR capabilities to a suitably equipped, preexisting next-generation CMS still offers a compelling value proposition when compared with costly, time-consuming, and frequently risky, in-house development.

A company's hardware costs also depend on its existing infrastructure. Finally, the level of outside consulting expertise that a company uses will also affect its final costs for implementing an eMDR system. When the company selects the right method of implementation, eMDR will yield significant ongoing cost savings.

Calculations of typical costs for implementing an eMDR system assume that the company already possesses a complaint management or other system for storing or tracking adverse events. Cost estimates for this component vary widely according to the number of licenses or locations purchased, optional features, and professional service fees.

Table III. (click to enlarge) Costs for in-house development of an eMDR system compared with those for purchase of an off-the-shelf eMDR systsem. All figures are estimates and may vary according to the scope of the individual company's implementation.
Source: FDA.

FDA estimates that a company that submits 1500 eMDRs per year will save approximately $80,000 (72% of estimated total costs) during the first year alone. By year two, after the transition from paper to e-reporting is complete, the savings will be $87,000 (78%).6 A more pragmatic view would include hardware, software development, licensing, and implementation costs (see Table III).

Assuming an initial capital outlay of $70,000 (eMDR purchase, EDI software purchase, implementation support, and EDI hardware) and annual eMDR transmission costs of $31,000 in year one, and $24,000 in years two-n, the two-year ROI is an impressive 1.39. Thus, the eMDR system will pay for itself in a little over one year.6

Although CDRH continues to accept paper reports, it is no longer accepting MDRs on CD or DVD media 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 executives, planning an e-reporting strategy now will help their companies to avoid a compliance crunch later.


References

  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: , 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.
  6. FDA Electronic Submissions Gateway: Return on Investment [online] (Rockville, MD: Center for Devices and Radiological Health, FDA, 2007 [accessed 8 July 2008]); available from Internet: www.fda.gov/esg/ROI%20presentation/return_on_investment.html.

Peter Hyman is a product manager at Sparta Systems (Holmdel, NJ).

Copyright ©2008 MX
Hide comments
account-default-image

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish