Electronic Medical Device Reporting 13140

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."

It's only a matter of time until FDA makes good on its promise of action. FDA's Center for Devices and Radiological Health (CDRH) is 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 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 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.

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.²

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.

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 way 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 acknowledgment 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).³

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, 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 (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 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.

A third reason involves the not-so-small matter of acknowledgments (ACKs) and negative acknowledgments (NAKs), which are cornerstones of all electronic reporting systems. In an automated system, such acknowledgments are essential for proper execution of data transfers, retries, process flow, and error handling. Many systems provide acknowledgments 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 acknowledgments. 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 acknowledgment, as follows.

It is the format of the third acknowledgment that has slowed software vendors and users from being able to fully transition to eMDR. Instead of a structured XML file, this acknowledgment 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 acknowledgment 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 acknowledgment for all eMDRs that it receives.

As knowledge of FDA's eMDR system proliferates across the device industry, and as clarity emerges on the challenge of acknowledgments, 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 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.

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

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. 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 start-up costs. 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.

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%).⁶ A more pragmatic view would include hardware, software development, licensing, and implementation costs.

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.⁶

Although CDRH continues to accept paper reports, it is no longer accepting MDRs on CD or DVD media without special approval. Once the eMDR acknowledgment 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

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

Copyright ©2008 MX