Challenges in FDA Electronic Reporting for Medical Devices Manufacturers & the Solution - Alysidia

A Brief Introduction to FDA’s eMDR System

The U.S. FDA is the central drug regulating authority in the United States of America, and different countries in the world try to show compliance to the standard set by it. Reporting of medical devices is an important issue. In this regard, the FDA’s Centre for Device and Radiological Health (CDRH) has issued a rule requiring medical device manufacturers to submit their devices’ electronic reports instead of paper ones. This means that the medical device manufacturers, who are also MedWatch 3500A filers, must submit their 3500As electronically.

Who are the 3500A Filers?

The 3500A filers include:

• Device manufacturers
• Distributors
• Re-processors
• Hospitals
• Physicians.

The adoption of the eMDR system has replaced the submission of paper MedWatch report with an electronic report that will be in the XML format. All of these files shall be electronically transmitted through FDA’s Electronic Submissions Gateway (ESG).

Challenges in Adoption of Electronic Reporting

The adoption of the FDA’s eMDR System was done a decade back. However, 3500A filers are still facing issues while trying to convert to electronic system from paper-based system. Some of the common challenges they face in this regard are:

1. Lack of mandate
2. Complexities in the method of receiving acknowledgment from CDRH.

How to Overcome these Challenges?

To remain FDA-compliant, a 3500 A filer who has not yet converted to eMDR reporting because of these issues will have to overcome them and that too, within a short period of time. For this purpose, he can prepare a simple plan consisting of the following:

• A proper thought process
• Careful planning
• Designing
• Testing
• Implementation.

Beginning the Thought Process

What to Include in the Thought Process?

First, a 3500A filer should start by thinking about his business’s nature and scope. He should consider the areas where his expertise lies and how he can transition from a paper-based system to the electronic one. In this context, he can work on the following questions:

1. What process is currently practiced for MedWatch Reporting?
2. How many reports get prepared within a given amount of time?
3. How are these reports stored?
4. What is the amount of automation for MedWatch report generation currently?
5. Is there any integration of this reporting process with a Complaint Management System?

Reporting Pattern of MedWatch eMDR

In the current eMDR System, the MedWatch workflow reporting is done by XML-formatted output. A 3500A filer looking forward to shifting towards eMDR should know that this XML-formatted System must conform to FDA’s strict rules and regulations. For this purpose, he must organize the data storing and retrieving process equally. Showing strict compliance to this XML-formatted System will help a filer adopt the automated system and benefit him.

Making Comparison between Two Different Systems

It is essential to know the difference between the amounts of reports generated manually against the number of reports developed through eMDR. This is important as this evaluation of report retrieval and archival impacts a reporting system’s overall functional design. A filer can carry out this evaluation by getting access to the report generating systems’ historical data. This will give him a better understanding of the report-generating system that works best for him. In this way, he will be able to select the reporting system that works best for him.

Strengths and Weaknesses of a Reporting System

A filer trying to develop a MedWatch eMDR-compliant system can determine whether his existing reporting system is capable of automation, retrieval, and storage as per the demand of eMDR or not. Suppose the filer finds his reporting system to be eMDR-compliant. In that case, he should begin the process of transitioning into eMDR.

Integrating the Complaint Management System

The filer can also check if he has an existing Complaint Management System or not. If he has a Complaint Management System, then he can check if

• His system is the part of the MedWatch reporting process or not
• He can expand this system to fulfill any future eMDR requirements.

If there isn’t any Complaint Management System, he can perform an analysis to determine how he can design and implement a Complaint Management System according to eMDR.

Performing a Self-Assessment

To determine the integrity of his reporting system, a filer can also perform a self-assessment process. Through this, he can determine:

• Report Acceptance Rate
• Frequency of Report Revision.

Report Acceptance Rate

By determining how many reports the FDA has rejected, the filer can know about deficiencies in his current data capturing system or reporting.

Report Revision Frequency

The filer’s ability to understand the report revision requirements will create a direct impact on system design.

How to Conduct Planning?

Once the filer has reviewed and conducted a need analysis of his current MDR methodology, the next step he should take is migration. It is a crucial step, as in it, the policies designed for manual paper reporting are reviewed and modified for eMDR’s accommodation.

Whom to Involve in Planning?

In this phase, the filer can involve stakeholders from:

• Businesses
• QA Staff
• Technical Staff
• Regulatory Staff.

Roles & Responsibilities of the Participants

With the participants mentioned above, the stakeholder can

• Support application and hardware infrastructure
• Conduct an end-to-end review process for assessing the risks and decision points
• Leverage common processes
• Isolate and document uncommon processes.

What to Consider while Planning?

Before starting the planning, the filer can consider the following:

• Based on the level of activity, any one of the given three methods:
  • CeSub: A downloadable program allowing the end-user to enter MDR data interactively.
  • WebTrader: A web-based portal for XML-formatted files transmission either from CeSub or from an in-house solution.
  • Electronic Data Transfer (EDI): Used to send one or multiple XML formatted eMDR files to FDA through an automated process that uses the EDI tool.

Note: All of these methods have been devised by FDA regarding eMDR submission.

• Ability to handle FDA’s acknowledgments
• Evaluation of technical infrastructure, software, digital certificates, and databases, etc
• Personnel evaluation, i.e., staff with additional expertise or consultation from a third-party
• Budget and timeline of the project.

Which eMDR Submission is the Most Appropriate?

As mentioned above, FDA has three methods for eMDR submission. It is up to the filer to determine the method that is most appropriate for him.

CeSub

This method uses an interactive wizard to generate one report or one update at a time. It is not in connection with any Complaint Management System. This option is cost-effective for organizations that only have few reports to manage. Such organizations can create and transmit valid XML files to the FDA by using this method.

WebTrader

WebTrader is for those e-reporters that use XML reports but do not have a considerable amount of these reports for submission. Using WebTrader, organizations can create their account with the FDA to securely transmit files created by CeSub or by an in-house solution.

EDI

The EDI software is linked with the Complaint Handling System and is used for moderate to high-volume submissions. EDI implementation requires a setup that includes hardware support as well as technical staff support requirements. With EI, one can transmit XML files in an entirely automated fashion to reception and acknowledgment storage. Although this process is costly, it has the capability of returning the most significant ROI.

Integrating the eMDR into Current Application Infrastructure

When the filer has taken all of these mentioned above, he should start working on getting the new application infrastructure. This can be done in the following ways:

• Extending the current Complaint Management System or other Data System to integrate it with eMDR, or
• Designing a new system and then incorporating it into eMDR.

One of the most crucial determinants in extending the Complaint Management System is cost-to-modify versus cost-to-implement versus cost-to-scratch versus expected benefits and results. But the filer should consider the FDA’s published specifications, whether he decides to extend his current Complaint Management System, build a new one, or purchase it from a third-party vendor. These specifications include:

• Detail file format
• Definitions
• Methods
• Rules
• Procedures.

The filer can also decrease the testing burden if he has already tested these solutions to some extent against these requirements.

EDI Transfers & eMDR Reporting

The eMDR reporting process requires EDI transfers. This is applicable in situations where the filer has either used WebTrader or EDI software. With the help of EDI, the filer can ensure that the security and integrity of his data transmission. This process of data encryption and verification is controlled with Digital Certificates. These certificates are:

• Used for the confirmation of sender as well as the receiver of the data
• Deliver only those files that are intended for the other person.

EDI Planning & Assessment

EDI planning involves an assessment to determine:

• authorized submitters (the people who will have Digital Certificates)
• use of the appropriate hardware platform
• the software platform to be used for transmission.

EDI Preparation & Acknowledgement Process

The filer should also prepare for handling the acknowledgment messages while he is in the EDI process. In this context, the FDA provides three acknowledgments:

• Acknowledgment regarding receiving the file package by FDA’s ESG (Electronic Submission Gateway)
• Acknowledgment regarding receiving the file package by CDRH
• Acknowledgment regarding the validation of data loaded in CDRH and its compliance with eMDR specifications. This confirmation only means the absence of any data or format errors with the transmitted file(s).

What should be done for the Successful Implementation of eMDR?

The elements that a filer requires for the successful eMDR implementation are:

• Handling of the acknowledgments mentioned above
• Analyzing their results
• Automating business processes based on these results.

Putting all of these into account can also save implementation time and reduce costs.

What to Include in Designing?

All of the elements discussed in the Thought and Planning process above will be brought together in Designing. This designing process shall include:

• A Complaint Management System to store Complaint, eMDR, and other global regulatory reporting
• Workflow Design and Process Flow Mapping
• Additional components (e.g., investigations, risk and regulatory assessments, CAPA, etc.) are essential for proper processing
• Designing the system components, including form layout, desktop and dashboard layout, queries, reports, filed names, process automation, etc
• Dealing with failures, preparing backup plans, and contingency report filing methods
• Factors such as security, permissions, group responsibilities, and group memberships will be present at different regulatory reporting/eMDR process stages
• The capability of handling potentially occurring scenarios such as follow-up reports and eMDR resubmission
• Developing of a project plan, schedule, and milestones.

Choosing a Complaint Management System

Interviewing

Choosing the appropriate Complaint Management System will begin from selecting and observing the vendors’ demonstration. These vendors will be capable of supporting all components of an eMDR solution. They can also handle the requirements of a broader Complaint Management System, which will include:

• Additional regulatory reporting for international health authorities
• Cost estimate
• Software
• Implementation
• Training
• Ongoing support
• Maintenance.

eMDR System as a Standalone System or as an Integrated System

As per the business’s need, the filer will decide whether to choose a standalone eMDR system or an integrated eMDR system. The standalone eMDR system can prove to be workable. However, an integrated complaint handling system and regulatory reporting platform primarily help achieve an efficient business process.

After choosing the appropriate software application for the organizational needs, the process of system designing can begin.

Major Components of the Designing Process

The following eMDR components will be part of the designing process:

• Process flow
• Required fields
• Identification of responsible groups for approval to report submission and report transmission
• Written User and Functional requirements and Standard Operating Procedures
• Establishment of appropriate resource assignments of the system’s discreet components’ management.

Additional Components of Designing Process

Additional components of the designing process can help in assisting the Complaint Management System. They include:

• Investigations
• Regulatory and risk Assessments
• CAPA and other international regulatory reports
• Reports
• Notification rules and alerts
• Establishment of security permissions for eMDR’s different phases
• Process for auditing trailing data and reports.

Other Requirements

Determining the Project Milestone

This step is necessary as it will help in assessing the ongoing process. This filer can apply this method to not only home-grown but also a third-party system’s implementation. While determining the project’s milestone, the filer must know about his goals and target. He should compare them with his project’s plan.

Plan for eMDR Resubmission & Follow-up

This is a mandatory process, and the filer must show compliance with FDA’s requirements while performing it. Things that the filer will have to cover in this process are:

• Processing of changed data only or updating the existing eMDR record
• Increasing the follow-up number or creation a new follow-up record.

Inclusion of Detailed Elements

The filer can also establish various detailed elements in this process, such as:

• Forms
• Field names
• Look and feel
• Workflow
• Approvals
• Reporting etc.

Planning of Backup Procedures

Defining the backup procedures is also necessary so that the reporting process can continue even during systems’ failure. For this purpose, the filer can conduct a Risk-Benefit Analysis of every phase of the eMDR cycle. This will help him in identifying the failure points, which can include:

• Backup systems/servers
• Reliance on paper report delays in an approved filing in case FDA system outage occurs
• Notification channels etc.

Commencement of Testing Phase

Commencing the Testing Phase

The testing phase will begin after the completion of system and data design. This includes migration from a Dev Environment to a Test or Validation Environment. Once this state is reached, it will be assumed that the system is ready for validation and user acceptance testing and that the configuration is locked.

Before end-to-end testing of the system, making preparations is necessary for establishing credentials with FDA. This process comprises writing a letter to the FDA, mentioning the authorized senders of data, and purchasing digital certificates.

How can the Above Information be used?

This information can be used for:

• Authenticating any data that is sent to FDA
• Setting up and testing the EDI connection for test eMDR files transmission.

What Tests should be performed?

The filer can perform tests for:

• Accountability of data fields and their exportation status
• XML output validation against DTD schema
• Acquiring of necessary FDA authority for submission of eMDR XML files
• Validation of security settings for data entry, approvals, and notifications
• Validation of XML outputs against data fields and 3500A’s hardcopy report
• Connections with FDA servers
• Data transfer to FDA
• Receiving, analyzing, and test post-processing of FDA/CDRH acknowledgments.

The filer should perform software design testing for the software that he will use for generating XML-formatted output. He should also validate that output against the FDA schema. If he does not perform the proper validation, then his submitted files will be rejected. To avoid rejection, the filer should perform both processes from the exact requirements set for field-level data. The extent to which software design testing and validation have been performed will reduce the testing and troubleshooting at the implementation time.

Final Step of Testing

The final step of testing involves user interface and functional testing. This is done to ensure the capturing, proper stoning, approval as per SOPs, and production in the required XML format of the necessary data elements. Any important legacy data should be imported along with appropriate testing and completion of verification.

Submission of Test Files

Test files containing both original and updated reports must be submitted along with the assessment of FDA results. If any formatting problem is present with the test data, then the FDA will highlight it.

Identification of Failures

It is also essential to identify potential failure scenarios and to take the appropriate action after their identification.

Implementation

Implementation will begin after the completion of testing and validation. Once the go-live date approaches, the filer should migrate the testing system in Test/Validation to a Production platform. Phased implementation works for most of the organizations. In this type of implementation, a legacy system is utilized for a certain period while the utilization of a new system gradually increases.

For an eMDR that is an extension of the existing Complaint Management System, there can be two co-existing methods. In the scenario where eMDR is replacing an existing system, the legacy MedWatch system can be phased out gradually. To help the users with transition, an eMDR system should be capable of generating XML as well as MedWatch formatted output.

What is the Reason for generating two Separate Outputs?

Generally, the XML output is not user-friendly and is less readable as compared to MedWatch-formatted output. Most users find the XML-formatted data entry screen or a printed report challenging. Therefore, having a paper form for comparing the output or development of a reverse XML program for making it human-readable should be considered.

Looking for FDA Compliance?

As experts in the field of medical device manufacturing and compliance-related matters, Alysidia has helped hundreds of medical device manufacturers globally to develop an FDA Compliant Electronic Reporting System. If you are a medical device manufacturer who has a hard time showing compliance to the FDA’s requirements, contact Alysidia today at Alysidia.com and get your FDA-compliant Electronic Reporting System.