Electronic Reporting: What you need to know to Comply with eMDR WHITE PAPER
Introduction eMDR, electronic medical device reporting, is an efficient method of submitting vigilance reports to the Center for Devices and Radiological Health (CDRH) at the FDA. Top medical device manufacturers, distributors, and reprocessors have implemented automated eMDR systems and, as a result, are benefiting from improved data accuracy, faster response from CDRH, and cost savings from the elimination of repetitive data entry, and even paper and shipping costs. An analysis performed by the FDA indicated that companies can save almost 80 percent by submitting reports electronically rather than by paper. Leveraging existing system capabilities will lead to additional incremental savings. As of August 13, 2015, manufacturers and importers were required to submit all MDR reports electronically. This new way of filing MDRs allows FDA to process, review and archive reports in a timely and effective manner. The eMDR reporting process serves as a replacement for the MedWatch 3500A report which requires an XML file to adhere to a structure dictated by the regulations. Creating the XML file is an involved process that requires a sophisticated tool to transform the data, including extracting, mapping, error-proofing, and formatting the data. The XML file is transmitted electronically via EDI to the FDA’s Electronic Submissions Gateway (ESG). EDI transfer ensures security and data integrity by assuring that data transmission is securely encrypted and verified. This process is controlled with Digital Certificates that are used to authenticate both the sender and receiver to one another to ensure files are delivered securely. Once the FDA has received the eMDR information, three separate acknowledgments are sent back to the reporting organization, confirming that the data has been received by the FDA, CDRH, and the adverse event database (MAUDE).
Abbreviations used: ACK 1 – Acknowledgment that the FDA received the eMDR submission through the Electronic Submissions Gateway ACK 2 – Acknowledgment that the submission reached CDRH ACK 3 – Indicates that the submission successfully loaded into the FDA’s adverse event database (MAUDE) system or notes any errors that occurred during validation and loading EDI – Electronic Data Interchange, the transfer of structured data, by agreed message standards, from one computer system to another without human intervention eMDR – Electronic Medical Device Reporting EQMS – Enterprise Quality Management System FDA – US Food and Drug Administration MAUDE – Manufacturer and User Facility Device Experience – CDRH’s database
www.spartasystems.com
2
Transitioning from a paper-based system to an electronic reporting platform will require thought, planning, design, testing, and implementation. The purpose of this paper is to help companies plan, design, test and implement and effective eMDR reporting system by careful up-front thought and planning. Thorough work on these fronts will ensure a smooth design phase, productive testing, and a successful implementation. There are currently new European Union medical device regulations.
Getting Started An internal assessment is required to understand the scope and nature of your business’ eMDR needs. Some evaluation points and questions to consider are: What is the current process flow for MedWatch Reporting? Who does what? How many reports are being generated in a typical month? Year? How are reports and/or report data stored? How much automation is currently in place for MedWatch report generation? Is the reporting process currently integrated with a complaint management system? What is your company’s trajectory? Are you planning to grow your business but keep the same headcount?
Topics of discussion eMDR provides the opportunity to develop an orderly workflow that moves from complaint processing to regulatory reporting, with the appropriate approvals and routing Assessing the current workflow that drives MedWatch reporting is essential to the transition to eMDR. Since XML-formatted output must conform to strict rules and adhere to standards, the process for storing and retrieving data that will be used must be equally organized to assure compliance. Implementation of eMDR offers the opportunity to automate what in many organizations is still a manual, paper-based process. Regulatory report volume will impact system design and resulting benefits Knowing the volume of reports that are generated will have an impact on the scope and design of the eMDR project by providing the necessary information to ensure the system is sized appropriately. Retrieval of historical data and report output must be designed into the system Establishing requirements for regulatory report data archival and retrieval should be evaluated as these requirements will impact the overall design of any reporting system. The ability to access data over a period of time and to retrieve eMDR reports from the system retroactively should be designed into any electronic reporting system. Furthermore, requirements for storing the actual output, not just the data, should be taken into account, as access to this information is especially important in the event of regulatory oversight and inspection. Leverage the strengths of your company’s existing reporting system How much automation is currently in place for existing MedWatch reporting? Any future reporting system could benefit from systems and procedures already in place – there is no need to reinvent the wheel. If there is a good process for reporting currently, leverage that capability and make it a foundation component for the new eMDR system.
www.spartasystems.com
3
Review the current complaint management system, assess its suitability for eMDR, and determine if the implementation of a next generation complaint management system is a requirement for eMDR Is there an existing complaint management system? If so, is this complaint management system already a part of the current MedWatch reporting process? Can it be leveraged or expanded to accommodate future eMDR requirements? If there is no complaint management system, perform an analysis as to whether one should be implemented in line with eMDR and how it would fit into the reporting process.
Planning The planning phase must involve stakeholders from business, QA, validation, and regulatory functions, as well as technical staff supporting both applications and hardware infrastructure. An end-to-end review of internal process must be conducted to assess risks and decision points. Moreover, common processes should be leveraged and divergent processes isolated and documented. At the end, the actual method and means of retrieving, transmitting, and auditing data will be critical. Important considerations for this step The FDA has various methods to submit eMDRs depending on volume and system sophistication – which one is right for your company? Will eMDR be an extension of an existing system or will it require the implementation of a new system? Evaluate technical infrastructure: hardware, software, databases, digital certificates, etc Evaluate personnel: will you require staff with added expertise or third party consulting support to transition to eMDR? Project budget and timeline
What is your starting point? Now that FDA requires MDR reports to be submitted electronically, here are two options: by manual process where MDR data is manually entered into FDA’s electronic submission tool, FDA eSubmitter, or via an automated process where one or more XMLformatted eMDR files are sent to FDA using an EDI tool. FDA often refers to the manual process of electronic submission as “low-volume” and the automated process as “high-volume,” but these titles can be misleading as volume is not the only factor forward-thinking companies consider when determining eMDR strategy. Other factors may include: Your organization’s compliance profile and desire to influence FDA’s perception MDR history Projected company growth, MDR trends, and resource plans Level of automation in current processes and systems
The manual electronic submission process through FDA eSubmitter requires the end-user to manually enter all necessary data into the FDA’s electronic version of the 3500A form. The data entered is converted into a valid XML file which can then be transmitted to the FDA via WebTrader or an EDI tool. FDA eSubmitter is an effective, compliant way to manage eMDR; however, because the eSubmitter can only handle one report at a time, requires more time and effort than completing a paper MDR, and requires organizations to manually manage the three FDA acknowledgments, it is not an efficient, best practices approach to regulatory reporting. The automated process of e-submission is an efficient and controlled exchange between your company’s system and the FDA’s system, making it the optimal method for sending eMDR information to the FDA. The automated process requires the reporting organization to develop or implement software to extract data from the company’s database and prepare the electronic submission. Because the software automatically extracts and packages the necessary data, automated eMDR requires minimal human intervention and can handle multiple report submissions simultaneously through an EDI tool. Automated eMDR systems allow organizations to automatically receive and process FDA acknowledgments and determine appropriate actions through automated business rules. While labeled as a
www.spartasystems.com
4
“high-volume” submission method, automated eMDR submission can be utilized by “low-volume” companies as well, providing savings in time, effort, risk, and costs by eliminating the steps involved in manual electronic submission. How will eMDR fit into to the current infrastructure? At this juncture, a decision must be made to either design a new system around eMDR or extend a current complaint management system or other data system to encompass eMDR. Assuming a legacy complaint management system can be extended, consideration should be given to the expected costs, benefits, and results from modifying the existing system versus implementing from scratch. The FDA has published specifications for what it expects from its e-reporters, detailing file format, definitions, methods, and rules and procedures. Any system, whether designed from the ground up, extended from existing format, or purchased from a third party vendor, must be tested against FDA requirements (see sources of additional information at end of document). The extent to which a solution has already been tested against these requirements or adopted within the industry may alleviate the volume of testing work required. Planning for EDI will require Digital Certificate purchase and assessment of which hardware platform to use (a corporate gateway or a standalone server) and which software platform will be used for transmission. A fully automated system holds the potential to return the most significant ROI. Along with EDI preparation, your company will need to plan for handling FDA acknowledgment messages. Handling the three acknowledgments, parsing their output, and automating business processes based on their contents are critical elements for a successful eMDR implementation. Previous testing and verification of acknowledgment receipts by the eMDR solution provider can help alleviate testing cost and reduce implementation time. Will your organization require consulting or supplementary staffing resources to set up the EDI framework or conduct implementationrelated tasks in the complaint management system? A successful implementation of any system will require coordinating the required resources and ensuring their availability at the appropriate times in the project plan.
Design Design of an eMDR system will bring together the elements discussed and reviewed throughout the initial planning phases. System design will include: Choosing a complaint management system for storing complaints, eMDR, and other global regulatory reporting Developing a project plan, timetable, and milestones Process flow mapping and workflow design Establishing security, group memberships, permissions, and responsibilities at different stages of the regulatory reporting/eMDR
process Designing system components, including form layout, desktop and dashboard layouts, queries, reports (as an adjunct to eMDR), field
names, and process automation Determining which additional components (e.g. investigations, risk and regulatory assessments, CAPA, etc) are integral to proper
processing in a holistic complaint management process Handling “what-if” scenarios, such as eMDR follow-up reports Failure handling, back-up plans, and contingency report filing methods
Topics of discussion Select a complaint management system that works for your business The process of choosing a complaint management system begins with interviewing and observing demonstrations by vendors who provide the capability to support all components of an eMDR solution as well as the requirements of a broader complaint management system, including additional regulatory reporting for international health authorities. Included in this vendor analysis would be a cost estimate for software, implementation and configuration, training, and ongoing support and maintenance. A key factor to consider is whether the eMDR system will be standalone or integrated with a complaint management system. A standalone system may meet the
www.spartasystems.com
5
needs for a company with low-volume reporting, but in most cases, the most efficient business process will be achieved from a joint complaint handling and regulatory reporting platform. The optimal choice will be the system that best meets the needs of the business. Although historically internal development was viewed as an option, homegrown systems are often too costly to develop and maintain on an ongoing basis and companies are instead choosing to adopt best-in-class software. By clearly defining the project plan, timetable, and milestones, your company can track progress throughout the course of the project Regardless of whether your organization chooses to implement a homegrown system or a third party system, project milestones must be clearly defined so that an ongoing assessment of progress can be made. Understand goals and targets and compare them frequently against the project plan. Establish process flow, form design, and group permissions and responsibilities The design process will address critical components of eMDR such as process flow, required fields, specification of groups responsible for approvals prior to report submission, and the process of report transmission. Form layout and field names, desktop and dashboard layouts, queries, and reports should reflect true business needs. User and functional requirements and standard operating procedures will need to be documented. The appropriate resources necessary to manage development of the system components will need to be assigned as part of the design phase. Round out your complaint management system with components that provide value to your business Determine which additional automated quality processes, such as investigations, regulatory and risk assessments, CAPA and other international regulatory reports, have the potential to augment the complaint management system. Design and configure reports, notification rules, and alerts that are critical to automating your business processes. Establish security permissions for different phases of the eMDR project life cycle and a process for audit trailing data and reports. Consider how to handle eMDR follow-up and supplemental reports Your organization should develop a plan for eMDR follow-up reporting. This process must be designed into the eMDR workflow to accommodate FDA requirements. Follow-up and supplemental reports with new data, whether updated or additional, can be sent to the FDA in two ways – by submitting only the new data or by sending the new data along with the original data. Don’t be caught off guard – plan how to handle system failures Define back-up procedures so that if one or more system failures occur, report processing can continue. Identify failure point and mitigation steps by conducting a risk analysis of each phase of the eMDR life cycle – from data entry to e-submission. Potential mitigation steps could include the use of back-up systems and servers, fallback to paper reports, approved filing delays in the event of FDA system outage, and notification channels.
Testing Once system and data design have completed, the system is migrated from a development environment to a test or validation environment, marking the beginning of the testing phase. At this stage, it is assumed that the configuration is locked and that the system is ready for validation and user acceptance testing. Prior to being able to test the system end-to-end, preparations must be made to establish credentials with FDA by purchasing digital certificates and submitting a letter to FDA stipulating who is authorized to send data. These credentials will be used for authenticating any data sent to FDA. In addition, the EDI connection for transmission of test eMDR files will need to be set up and tested. Thorough testing requires multiple steps: Test that all data fields are accounted for and can be exported Test that XML output is validated against the DTD schema Acquire necessary authorization from the FDA to submit eMDR XML files Validate security settings for data entry, approvals, and notifications Validate XML output against data fields and hard copy 3500A report Test connection to FDA servers
www.spartasystems.com
6
Test data transfer to the FDA Analyze and test receipt and processing of FDA/CDRH acknowledgments
The design of the software used for generating XML-formatted output must be tested and the system’s output must be validated against FDA requirements. Proper validation is mandatory; any improperly formatted files that are submitted to the FDA will be rejected. Ideally, the backend reporting process and the data input process should be developed in parallel, as both processes should be operating from the same set of requirements for field-level data. The burden of testing and troubleshooting can be greatly reduced by selecting an eMDR solution provider that has already performed validation testing. Finally, user interface and functional application testing should be performed to make certain that required data elements are captured, stored properly, approved according to SOPs, and produced as required in XML-format. Any legacy data that is needed should be imported and the appropriate testing and verification completed. Upon receiving test files from your system, the FDA will respond with a message indicating if any formatting problems occurred with the test data. Possible failure scenarios should be tested to ensure that different versions of the third acknowledgment are processed correctly and the system takes the appropriate action when a failure is identified.
Implementation As the go-live date approaches, the tested system in the test or validation environment should be migrated to a production platform. For most organizations, a phased implementation, where a legacy system is kept alive for a period of time while the new system is increasingly utilized, provides a manageable approach to changing over to the new system. If eMDR is designed to be an extension of an existing complaint management system, eMDR reporting and the legacy reporting method can coexist indefinitely. If eMDR will replace an existing system, over time the legacy MedWatch reporting system will be phased out. To aid end-users with the transition, an eMDR system should have the capacity to generate both XML and MedWatchformatted output, as XML output is not as user friendly and is less readable then a formatted MedWatch form. Comparing data that resides on a data entry screen or a printed report with an XML file is challenging for most users. Your organization should strongly consider having a paper form to compare with the XML output or developing a “reverse-XML” program to make the output easier to read.
Conclusion There are substantial benefits to implementing a best practices eMDR system. eMDR offers real cost savings to your organization. The FDA has performed an analysis that indicates companies can save almost 80% in their operational costs using e-submitting reports. Actual ROI analyses conducted by medical device organizations have shown savings even greater than the FDA ROI model. Many companies can leverage existing investments to reduce the cost of eMDR compliance. eMDR adopters may positively influence FDA’s perception of their compliance profile.
Sparta Systems, an industry pioneer and global leading provider of enterprise quality management software (EQMS) solutions, enables businesses to safely and efficiently deliver their products to market. The Company’s quality management platform solutions include TrackWise, Stratas and newly acquired 123Compliance, providing customers a choice of on-premise and cloud offerings. For more than 20 years, Sparta Systems has been a trusted standard among highly regulated industries, used by quality, manufacturing and regulatory affairs professionals to manage compliance, reduce risk and improve safety across the global enterprise. Headquartered in Hamilton, N.J. and with locations across Europe and Asia, Sparta Systems maintains an extensive install base in the pharmaceutical and biotechnology, medical device, electronics manufacturing and consumer products markets among others. Read more about Sparta Systems and its award winning solutions on the corporate website or blog. www.spartasystems.com | http://blog.spartasystems.com
Global Headquarters 2000 Waterview Drive Hamilton, NJ 08691 (609) 807-5100 (888) 261-5948 info@spartasystems.com
European Offices Berlin | London europe-info@spartasystems.com
Asia Pacific Offices Singapore apac-info@spartasystems.com