By Joby George
The FDA’s Center for Devices and Radiological Health (CDRH) posted a notice of draft guidance that will require all medical device adverse event reports to be submitted electronically. While the process of electronic submission of data is a more efficient and traceable means for reporting, it could prove to be a very long and challenging road for the average medical device manufacturer to transition from its current paper-based reporting process to an electronic reporting process.
To ensure success, this transition needs to be very carefully planned out and executed to guarantee continued compliance and ongoing integrity with regard to the company’s product adverse event reporting and customer satisfaction.
Companies with a well-planned enterprise quality management initiative that ties together quality management across the corporate manufacturing operation will likely have a far easier time managing the transition to electronic-based reporting, as well as successfully mitigating risks of any ongoing compliance challenges. Such programs create a regimented and holistic approach to quality and adverse event monitoring, tracking, and reporting, therefore creating a solid foundation of standardized quality data within the confines of well-defined workflows, which easily facilitates transitioning from a paper-based reporting process to an electronic reporting process.
However, regardless of whether your organization has an enterprise quality management system in place with an integrated eMDR solution, or plans to develop a customized eMDR solution, it’s vital that organizations approach eMDR transition with extreme care. A holistic, proactive strategy for managing the transition to electronic adverse event reporting will enable companies to comply with the recently announced eMDR notice of draft guidance, while also sustaining product safety.
Smooth Transition To Electronic Adverse Event Reporting
There are six key steps that can be employed companywide to help successful transition to electronic adverse event reporting. These steps are broken down as follows:
1. Discovery — Examine current enterprise manufacturing and adverse reporting processes, mapping out current workflows including technology used, chain of responsibility, and any points where data is moving from one system (or paper-based container) to another. Highlight any issues or pain-points with the current process, including potential areas of data loss, manual and/or inefficient time-consuming steps, and steps that are incompatible with the draft guidance. Define the goals for what the process should look like for the company under the draft guidance, and determine the delta between the current state and the future state of the adverse reporting process while addressing all of the relevant issues and pain points. Start with a thorough, comprehensive, and very candid self-evaluation that asks some very critical questions. Examples of these questions include:
2. Planning — Leverage the framework created in step one to fully develop the transition plan, taking careful consideration to follow up on the progress of efforts to address potential issues or challenges in the process, addressing each one in turn within the transition plan (include all issues and pain points identified, even if the resulting action is that there will be no change in the process at this time). Whenever possible, utilize common processes that have previously been employed successfully, and quickly disregard any potentially divergent processes that could cause problems during this complex process.
Map out in detail the projected flow of electronic reporting to and from the FDA in terms of effectively receiving, transmitting, and auditing the electronic report. Upon completion of draft one of the plan, share it with leaders of each business unit that will be affected by this transition, and request feedback and suggestions from each to assist in developing a stronger, more effective plan.
3. Design — Evaluate any electronic reporting functionality within currently deployed and/or purchased electronic systems to determine whether it will meet the needs of the new eMDR system design. If appropriate, utilize the existing system. If existing capabilities are insufficient (or if there is no system currently in place), evaluate available options including third-party applications and custom-built solutions (note that most custom-built applications are far more expensive than existing solutions, so be sure to do a thorough cost/benefits evaluation before selecting this option). Be sure all potential solutions include process flow mapping and workflow design, as designing an effective system that encompasses these elements (working in proper order and alignment) will result in greater efficiency and significant cost reduction in the long run.
Once a technology solution is selected, design the eMDR solution based on the developed plan. The design should include workflows, process flow mapping, and designs for all system components needed, such as form layout, desktop and dashboard construct, queries, reports, field names, process automation, and so on.
4. Build — Once the system and process designs are complete, build the system to the designed specifications. However, as with any design process, there will likely be issues or design elements that were not considered, challenges that were not identified, and risks that have not been planned for. Conduct unit and functional testing as functionality is completed to ensure that the system is functioning as expected. Also, identify all issues and potential risks as they arise, while remaining focused on accomplishing the goal of establishing a successful eMDR process.
5. Testing — Once the system is completed, conduct system-level tests to identify any remaining issues or points of failure. After verifying the system functions as expected, outline acceptable failure scenario response values (i.e. length of time to corrective action, notification trees, etc.), and run the new system through failure scenarios to measure actual responses against acceptable responses. If necessary, modify the system to close the gap between actual and acceptable responses.
6. Implementation — Once steps one through five have been successfully completed, begin the implementation process by notifying all departments and teams that will be affected by the new system and collecting final sign-off from all necessary parties. All training and internal messaging should also be completed at this time.
Implement the solution at a time that will cause the least impact on productivity (such as during an evening or weekend). In the early stages of utilization, observe eMDR users and approvers, elicit feedback, and monitor complaints and support calls to understand how effectively the system is working and how well the correct data is flowing to and from the FDA. Take any necessary corrective action if the system is not working to corporate standards.
Organizations following these comprehensive steps and working diligently to test and proactively counteract any potential issues will be in a strong position for a successful, smooth transition to eMDR. For organizations opting to develop a customized solution rather than using a centralized enterprise quality management system, additional steps must be taken to ensure their eMDR system is tightly integrated into the greater, companywide quality management program. The two processes must run in parallel and integrate where necessary to ensure a single, holistic view of quality and safety across the enterprise.
As the regulatory community continues to tighten the reins on the medical device industry, rigid, tested, and well-deployed systems like those for eMDR or enterprisewide quality management are critical to maintaining compliance. Organizations with the ability to enhance and grow their quality/adverse event reporting mechanisms, rather than constructing or reconstructing solutions every time a new regulation comes out, will have the advantage of a more cost-effective, agile, and flexible environment that can more easily drive corporate regulatory compliance.
About The Author
Joby George is a product manager at Sparta Systems. Prior to joining the product management team, Mr. George was a solutions delivery manager and presales engineer at Sparta Systems. He has a B.S. in computer science and economics from Rutgers University.