A Primer to the Structure, Content and Linkage of the FDA's Manufacturer and User Facility Device Experience (MAUDE) Files.

INTRODUCTION AND
BACKGROUND: The US Food and Drug Administration (FDA)'s Manufacturer and User Facility Device Experience (MAUDE) database is a publicly available resource providing over 4 million records relating to medical device safety. Using downloadable MAUDE files avoids limitations of the online MAUDE search interface. However, naive file usage can result in errors, while independent discovery of the nuances required to correctly work with the database can be time-consuming. Practical information is provided to shorten this learning curve and obtain accurate results when using the MAUDE database files. MAUDE FILE DESCRIPTIONS: The MAUDE database consists of 135 fields in four primary (Master Event, Device, Patient, Text) and two supplemental (Device Problems and Problem Code Descriptions) file types. When combined, these six files provide a detailed account of an adverse event or product problem report. Website instructions for joining the files are incomplete. Comprehensive details are provided to enable precise file linking. LESSONS LEARNED: MAUDE files have irregularities that must be understood to download and work with the data efficiently. Accurate results depend upon combining the files correctly and understanding the difference between report and event denominators. Appreciating data availability can facilitate successful MAUDE investigations.
CONCLUSION: The MAUDE database can provide key insights about medical device safety. Detailed information is provided about the structure, content and interrelationships of the MAUDE database files to enable investigators to use this valuable resource more quickly and accurately.

Introduction

The increasing number of big data repositories and analytical tools available for medical research is one of the exciting trends of the 21st century [123]. The US Food and Drug Administration (FDA)’s Manufacturer and User Facility Device Experience (MAUDE) database) is one such resource. MAUDE contains over four million medical device adverse event and product problem reports dating back to 1991. With nearly two thousand new adverse event and product problem reports submitted every day the MAUDE database is an important tool for monitoring and investigating safety issues involving medical devices. MAUDE has facilitated the identification and investigation of medical product problems ranging from cardiovascular and gynecological devices to stretchers and tanning beds [45678910111213].

While the FDA’s online MAUDE search engine provides a targeted way to look up small numbers of adverse event reports associated with specific products or problems, the search results are limited to the past 10 years and detailed information is not structured in a format that can be readily analyzed. In addition, the number of records returned for a given query is capped, and in a small sample study nearly half of the search results exceeded this limit.

The search engine limitations may be overcome by using downloadable MAUDE files provided by the FDA. However naive linking of the six MAUDE file types that comprise an adverse event record can result in erroneous findings, while understanding the nuances of the various file types and how they work together can be exceedingly time-intensive [1415161718192021].

The MAUDE database contains medical device problem and outcome information that can inform general reviews, specific product inquiries, and examination of adverse event reporting trends over time. The goal of this paper is to provide novice users with information gained through practical experience about the basic structure and content of the MAUDE database. Detailed information about the content, structure and technical issues of the files is also provided for more technical readers who need to obtain a complete picture of an adverse event report or an analysis database. The information detailed in this paper has the potential to shorten the learning curve and improve the accuracy or results obtained by researchers using MAUDE.

MAUDE Background

Medical devices encompass several thousand health care products, ranging from simple tongue depressors and bandages, to complex medical lasers and MRI machines. As defined by the FDA, a medical device is a product used to diagnose, treat, cure, mitigate, prevent or alter bodily functions. Although they may be combined with a drug as in the case of drug-eluting coronary stents, medical devices differ from pharmaceutical (drugs) or biological (blood, vaccine, gene or cellular) products in that they do not use metabolism, chemical or immunological means to achieve their primary intended purpose [22].

The MAUDE database contains adverse events and product problem reports involving medical devices, including reports of suspected device-associated deaths, serious injuries and malfunctions. The publicly available MAUDE database encompasses the releasable, medical device reporting information submitted through MedWatch Form 3500 (Form FDA 3500 A for Mandatory Reporting by Manufacturers and Form FDA 3500 for Voluntary Reporting by patients, health professional and consumers) [23]. MAUDE also includes adverse event information submitted via the FDA’s Alternative Summary Reporting (ASR) program [24]. Database records extend back to enactment of the Safe Medical Devices Act [25] and include reports submitted by user facilities since 1991, those from distributors and voluntary submitters since 1993, and from manufacturers since 1996 [26]. As shown in Figure 1, the vast majority of MAUDE reports are now submitted by manufacturers, and the number of submissions has grown exponentially over the last decade.

Figure 1

MAUDE Medical Device Reports through 2013 by Year Received and Reporting Source

The Utility of MAUDE

The FDA uses MAUDE reports to monitor device performance, detect potential device-related safety issues, and inform the risk-benefit assessments of these products [2728]. Health care professionals use MAUDE to review events associated with specific products, body systems or procedures [293031323334]. More than 120 articles referencing MAUDE have been published to date, the majority of these summarizing adverse events specific to a particular outcome, product or body system.

Two examples illustrate the potential of MAUDE: 1) In an investigation of complications associated with global endometrial ablation, Gurtcheff and Sharp8 identified injuries reported in MAUDE that were not yet identified in peer-reviewed publications, leading the authors to “encourage physicians to review the MAUDE database when considering the use of a new medical device, to research the possibility of complications not yet reported in the published medical literature.” 2) Hauser and colleagues [35] used information reported in the MAUDE database to investigate whether a new implantable cardioverter-defibrillator (ICD) lead coating effectively prevented insulation failures caused by abrasions. Based on their findings, the authors concluded that the material “did not prevent these abrasions” and raised awareness of a potential product issue subsequently observed by others [3637]. Finally, in our own research, we are using information in the MAUDE database to explore early predictors of medical device recall [38].

Limitations of Using MAUDE Search Results for Research Studies

The FDA provides access to MAUDE information through three mechanisms (Figure 2): an online simple (single-parameter) [39] or advanced (multiparameter) [40] search interface or downloadable data files [26]. While the online search engines are extremely convenient, information obtained using these interfaces has several limitations:

Figure 2

Accessing MAUDE Data

The single-parameter (a) and multi-parameter (b) online MAUDE search interfaces, and an example of files available from the MAUDE download files interface (c).

Results are restricted to reports made within the past 10 years.

Only a small subset of MAUDE fields is provided in the comma-separated value file that may be downloaded from these results (Table 1).

Table 1

Only a Fraction of Data is Available when Exporting MAUDE Online Search Results to Excel

REPORT NUMBER	MANUFACTURER	BRAND NAME	DATE REPORT RECEIVED	PRODUCT CODE	EVENT DATE	EVENT TYPE	EVENT TEXT
Web Address: http:/www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfMAUDE/detail.cfm?mdrfoi_id=3545674
2938836-10124	ST. JUDE MEDICAL; INC.; CRMD	RIATA ST OPTIM ACTIVE FIXATION	12/31/2013	LWS	10/4/2013	Malfunction	Event Description: IT WAS REPORTED THAT DURING DEVICE REPLACEMENT; LEAD DISLODGEMENT WAS NOTED. TESTS INDICATED THAT ALL THE ELECTRICAL PARAMETERS WERE GOOD AND THE PHYSICIAN ELECTED TO LEAVE THE LEAD IN ITS CURRENT POSITION. NO FURTHER ISSUES WERE REPORTED AND THE PATIENT CONDITION WAS GOOD AFTER THE EVENT. Manufacturer Narrative: ALL INFORMATION PROVIDED BY MANUFACTURER; NO MEDWATCH FORM WAS RECEIVED.
Web Address: http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfMAUDE/detail.cfm?mdrfoi_id=3545673
2938836-10118	ST. JUDE MEDICAL; INC.; CRMD	RIATA ACTIVE FIXATION	12/31/2013	LWS	8/12/2013	Malfunction	Manufacturer Narrative: ALL INFORMATION PROVIDED BY MANUFACTURER; NO MEDWATCH FORM WAS RECEIVED. Event Description: IT WAS REPORTED THAT DURING DEVICE CHANGE OUT DUE TO NORMAL ERI; MINOR INSULATION ABRASION WAS OBSERVED ON THE PROXIMAL PORTION OF THE LEAD. NO ELECTRICAL ANOMALIES WERE DETECTED. LEAD WAS REPAIRED WITH A LEAD REPAIR KIT AND REMAINS IMPLANTED. PATIENT WAS STABLE AND EXPERIENCED NO COMPLICATIONS DUE TO THE PROCEDURE.
Web Address: http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfMAUDE/detail.cfm?mdrfoi_id=3545098
2938836-10101	ST. JUDE MEDICAL; INC.; CRMD	RIATA ACTIVE FIXATION	12/31/2013	LWS	11/20/2013	Malfunction	Event Description IT WAS REPORTED THAT HIGH HV LEAD IMPEDANCE WAS OBSERVED VIA REMOTE TRANSMISSION. DEVICE WAS REPROGRAMMED AND IMPEDANCE MEASUREMENTS WERE NORMAL. A SUCCESSFUL INDUCTION TEST WAS PERFORMED. THE PATIENT CONDITION WAS GOOD AND WILL BE MONITORED. Manufacturer Narrative: ALL INFORMATION PROVIDED BY MANUFACTURER; NO MEDWATCH FORM WAS RECEIVED.

Details for an individually-selected search result record may be viewed in a web browser but the information is not provided in a structured manner that can be readily downloaded or analyzed (Figure 3).

Figure 3

Detailed Information from the MAUDE Online Search Interface is Not Readily Analyzed

Results are limited to 500 records per query which an inattentive user may miss (Figure 4) and which necessitates the use of narrowed search criteria, adding time to the process and potentially constraining the original question of interest.

Figure 4

Truncated Results with the MAUDE Online Search Interface

This example illustrates a listing of MAUDE results obtained using the single-parameter MAUDE search interface where the query returned more than the maximum 500 records.

Using the advanced search interface, a small sample study was conducted to explore the extent to which search engine results exceeded the n=500 upper limit record restriction. This study examined the 79 Class 3 medical devices assigned for review by the cardiovascular device panel [41]. One quarter (n=20) of the searches returned more than 500 results for 2013 alone, while 42 percent (n=33) of the same queries exceeded the count restriction for the 5-year period from 2009-2013. Often the easiest way to narrow the search results is to restrict the specified date interval; however, since the number of retrieved records is unknown, it can be quite time-consuming to iteratively determine date intervals that result in fewer than 500 records, while also minimizing the number of result files that must be separately exported and combined. For example, more than 500 coronary drug-eluting stents (Product Code NIQ) records were retrieved in 2013. Detailed iterations found that 2-3 week windows (equating to 16 date intervals) were necessary to optimize the number of results returned per year while staying below the 500 count maximum. Obviously, this manual process quickly becomes quite tedious if one wanted to revise the search to cover a longer time span or to investigate both drug- and non-drug eluting coronary stents.

To avoid the time constraint and the field and count limitations of the Search interface, the FDA makes available downloadable MAUDE data sets (Figure 2c). While these files allow one to explore complex questions, to span large time frames and to retrieve detailed report information, the individual files must first be imported and pieced together. This process can be much more complex than initially anticipated due to the lack of detail and inconsistencies in the online information describing the MAUDE downloadable files and their contents. The remainder of this paper focuses on documented tips and techniques for processing and combining these files based on empirically determined potential sources of error.

Organization of the MAUDE Files

As shown in Table 2, MAUDE files are grouped into four primary and two related supplemental files spanning a total of 135 fields:

Table 2

MAUDE Files and Content

MAUDE Files and Fields as defined on the MAUDE website. Added shading indicates file linking (see also Figure 5). Information in parentheses indicates the MedWatch Form 3500 source field.

Figure 5

MAUDE File Relationship Diagram

Master Event:the centerpiece to which all of the other MAUDE files eventually relate. Data in the Master Event file include adverse event and product problem information reported in sections B, E and H of the MedWatch Form 3500, along with detailed distributor and manufacturer contact and address information from MedWatch sections F and G.

Device: includes baseline reporting information and information reported in section D of the MedWatch Form 3500, including device identifiers such as manufacturer, product name and model number.

Patient: contains concatenated treatment and outcome information.

Text: encompasses MedWatch Form 3500 narrative information from sections B and H describing the adverse event and the manufacturer’s evaluation of returned devices.

Primary

The four primary file types provide options for selecting data for the current year current month, previous year (Device and Text files) or years combined (Master Event and Patient data, and early Device (before 1998) and Text (before 1996) data, and file changes.

Device Problems: links a MAUDE report to one or more device problem codes reported in section F of the MedWatch Form 3500.

Problem Code Descriptions: maps a device problem code to a short, text description.

Supplemental

Given the current file structure, a Device and a Text file are added each year and a complete MAUDE database covering information from 1991 to the present entails over 50 files.

When combined, the information contained in the six MAUDE file types provide a detailed account of a reported adverse event or product problem report. However, while accurate, MAUDE website instructions indicating that “All record types are linked via the MDR REPORT KEY” are incomplete. Figure 5 illustrates the full interrelationships among the MAUDE data sets. The nuances of each file type and specific considerations for joining the files are reviewed in the next section.

Detailed MAUDE File Information

This section discusses specific information about importing and joining files together as well as information about the content and structure of the files. In this discussion, MAUDE field names are displayed in italicized capital font, using the names provided on the MAUDE website.

Importing Files

The downloadable MAUDE files are provided as zipped files in which individual data elements are pipe-delimited. A header row containing field names is present for the Master Event and Device data sets, but labels must to be manually entered for the other file types. As such, when importing data, make sure the import process takes into account whether a header row is present.

While the MAUDE website indicates it may be necessary “to put in an extra character at the end of the first record prior to importing the file, otherwise the last column of data may be lost”, in practice we did not find this step to be required when importing data into SAS 9 or RStudio. However, readers should be alert to the presence of rare, but potentially problematic, non-printing line-feed (LF) characters. Not only can these invisible characters result in the truncation of data (at the point of the LF occurrence) within the original record, but data following the LF character may be subsequently processed as a ‘new’ entry, causing errors in record counts and data type incompatibilities. When importing data into SAS, this issue was circumvented by use of a TERMSTR=CRLF option in the INFILE statement [42].

Many files used double quotation marks to denote an exact word or phrase, e.g., THE “BATTERY VOLTAGE TOO HIGH” ALARMS WERE ACTIVATED, or to indicate inches, e.g., 7” MICROBORE NON-VENTED EXTENSION SET. And in the foidevthru1997 file, a double quotation mark was also intermittently used to signify missing values, e.g., |”|”|”|. The QUOTE option in RStudio was necessary to ensure appropriate handling of all files containing double quotation punctuation. In SAS, special handling of double quotations was only necessary when they were used to signify a missing value, in which case the TRANSTRN option can be used to identify and remove them when importing data.

Finally given the size of the MAUDE download files, compression and keyword indexing facilitated more efficient processing in SAS. Due to the number of records in each file, it is typically impractical to review the imported data file contents in entirety; however, import problems can often be identified by:

Checking record counts.

Ensuring data types are assigned as expected.

Comparing the first and last imported records to the raw data files.

Generating descriptive summaries or tables of individual fields.

A GitHub repository with examples programs that can be used to import the MAUDE data sets into SAS is available [43].

Master Event Data

Data Availability

Although the majority of records are reported by the device manufacturer (Figure 1), approximately 5 percent of reports are submitted by user facilities, voluntary submitters (including health professionals or consumers/patients), and distributors. Data availability for certain fields (e.g. DISTRIBUTOR NAME) depends on the reporting source.

Linking to Other MAUDE Files

The Master Event file includes two database key fields: MDR REPORT KEY which identifies unique reports and is important for linking most of the MAUDE files together and EVENT KEY which is an internally-generated field used to identify unique events. MDR REPORT KEY is unique within the Master Event file whereas EVENT KEY is not.

The MAUDE website states “A distinct master event data record will be present for each source reporting an event. In other words, if a User Facility, Distributor Manufacturer, and voluntary submitter all report an event, there will be four event records.” [26] Approximately 8 percent of the Master Event file records share an EVENT KEY, that is, have two or more unique records present in the MAUDE database identified as pertaining to the same event. One might surmise that duplicate EVENT KEYs correspond to different REPORT SOURCE CODEs (M=manufacturer, D=distributor, U=user facility and P=voluntary submitter). However, in practice a large majority of MAUDE reports sharing an EVENT KEY are submitted by the manufacturer with many of the connected reports pertaining to devices sharing a common lot number.

Technical Tips and Considerations

An important consideration when working with the downloadable MAUDE files is whether the research question of interest pertains to unique reports or unique events. If a question involves unique events, one must incorporate the Master Event file EVENT KEY when preparing data for analysis, even if none of the other Master Event file data is pertinent to the question of interest.

Device Data

Device data is available for nearly 90 percent of MAUDE reports. Although the Device file contains baseline reporting information, the baseline reporting requirement was removed in 2008 [44], and baseline data is not supplied for most records.

The Device file contains an MDR REPORT KEY field, facilitating the linkage of this file with Master Event data. While the vast majority of the Device file records are associated with only one device (Master Event file NUMBER DEVICES IN EVENT = 1), there are more Device file records than MAUDE reports since a report may be associated with multiple products (Master Event file NUMBER DEVICES IN EVENT > 1). That is, MDR REPORT KEY is not unique within the Device file. This may arise, for example, if the individual submitting an adverse event report about a hip replacement system lists all of the hip system components, including the metal-on-metal hip implant, the metal liner and the femoral stem.

In other cases, the same problem may be linked to different instances of a medical device. For example, an infusion pump problem observed eight times, each time involving a different pump, may be submitted as one event tied to eight Device file records. The combination of MDR REPORT KEY and DEVICE SEQUENCE NO uniquely identifies a Device file record. Figure 6 illustrates the relationship between the Master Event and Device files.

Figure 6

Master Event and Device File Mapping

Included in the Device file is a DEVICE REPORT PRODUCT CODE field, a unique three-letter identifier (Supplemental Table 1) indicating the type of device associated with the reported event, as determined by the submitter There are currently over 6,000 medical device product codes, and the list is updated weekly [41]. Virtually all of the Device file records include a DEVICE REPORT PRODUCT CODE, and this field is helpful for selecting a subset of records pertaining to a product of interest. However, readers should keep in mind that product codes are neither structured in a hierarchical manner nor validated upon entry. For example, a report about a pacemaker lead problem may be recorded as a problem with the pacemaker itself, or even with an unrelated product.

Supplemental Table 1

FDA Medical Device Product Code Examples

PRODUCT CODE	DEVICE NAME
DTB	Permanent Pacemaker Electrode
DTC	Analyzer Pacemaker Generator Function
DTD	Pacemaker Lead Adaptor
DTE	Pulse-Generator, Pacemaker External
DTF	Tools, Pacemaker Service
DTG	Magnet, Test, Pacemaker
DTI	Sizer Heart-Valve, Prosthesis
DTJ	Holder, Heart-Valve, Prosthesis

Patient Data

Treatment or outcome information is present for approximately three-quarters of Patient records, though only a quarter of records include both. Patient identifying information populated in section A of the MedWatch Form 3500, including age at the time of the event, date of birth, gender and weight, is not provided in the publicly-available MAUDE database.

Similar to the structure of the Device file, a reported event may be linked to several patients, and there are more Patient file records than MAUDE reports. This typically occurs when a manufacturer submits one report for a problem observed in multiple individuals. In these cases, the Patient file includes n = Master Event file NUMBER PATIENTS IN EVENT records, each sharing the same MDR REPORT KEY but having a unique, sequentially assigned PATIENT SEQUENCE NUMBER ranging from 1 to n, comparable to the configuration shown in Figure 6. Consequently the combination of MDR REPORT KEY and PATIENT SEQUENCE NUMBER uniquely identifies a Patient file record.

When using the outcome or treatment information contained in the Patient files, it is important to note that their structure differs from the instructions on the MAUDE website when multiple patients are linked to a MAUDE report.

Using the OUTCOME field as an example, the online MAUDE information indicates the field is structured as: “Sequence Number||’,’|| Outcome -- multiple source type, separate by ‘;’”. When a single patient is linked to a report (Master Event file NUMBER PATIENTS IN EVENT = 1), this pattern holds true. For example, when a report is associated with one patient having outcomes indicative of a life-threatening event (OUTCOME=L), requiring intervention (OUTCOME=R) leading to hospitalization (OUTCOME=H), the OUTCOME field displays as “1,L;2,R;3,H”. Enumerating a certain outcome of interest requires simply counting mentions of a particular code or summing over indicator variables signifying the absence or presence (0/1) of an individual outcome as shown in Table 3.

Table 3

Patient Outcome Field Structure when One Patient is Linked to a MAUDE Report

MDR REPORT KEY	PATIENT SEQUENCE NUMBER	OUTCOME	OUTCOME EVENT INDICATORS
			HOSPITALIZATION	REQUIRED INTERVENTION	LIFE-THREATENING	DEATH
123	1	1,H;2,R;3,L;	1	1	1	0
234	1	1,D;	0	0	0	1
345	1	1,H;2,R;	1	1	0	0
456	1	1,R;	0	1	0	0
		Totals:	2	3	1	1

This table shows four representative Patient file records, each associated with a different MAUDE report. The Outcome column depicts the raw data as it would be presented in the native MAUDE Patient file: H=Hospitalization; R= Required Intervention; L=Life-Threatening; D=Death. User-added 0/1 Outcome Event Indicator variables (e.g., Hospitalization, Required Intervention, Life-Threatening, Death) can facilitate record summarization as shown in the Totals row.

However when a MAUDE report is linked to multiple patients, the structure of the OUTCOME field deviates from the specified pattern in an important way – namely the contents of the OUTCOME field are not specific to the patient designated by the PATIENT SEQUENCE NUMBER. Rather the OUTCOME field represents a sequential concatenation of findings across patient records sharing a common MDR REPORT KEY. That is, the outcomes of each successive patient associated with an MDR REPORT KEY are prepended to the results from all of the previous patients having the same MDR REPORT KEY. This is best demonstrated through an example. Table 4a depicts a case in which a single adverse event report is associated with five patient records (Master Event file NUMBER PATIENTS IN EVENT = 5). As can be seen in this table, the first patient associated with the adverse event report has three outcome results: 1) hospitalization (H), 2) required intervention (R), and 3) life-threatening (L). The next patient record linked to this event (PATIENT SEQUENCE NUMBER = 2) contains both the OUTCOMES for the second patient: 1) hospitalization, and those of the first patient; the third record in the series prepends the results for the next patient, and so forth.

Table 4a

Raw Outcome Data

Table 4. Patient Outcome Field Structure when Multiple Patients are Linked to a MAUDE Report

Table 4a shows the raw Patient file outcome data for an example in which five patients are associated with the same adverse event report. Color coding is used to highlight the outcomes pertaining to a specific patient: cyan for patient 1, magenta for patient 2, yellow for patient 3, gray for patient 4 and green for patient 5. In the raw data, the OUTCOME field for the 3rd patient associated with the adverse event report actually contains the outcomes for the 1st, 2nd, and 3rd patients. Erroneous, inflated totals for individual outcome events would be obtained if one were to naively count the mentions of each particular code as is illustrated in the user-added Hospitalization, Required Intervention, and Life-Threatening Outcome Event Indicator columns and Incorrect Totals row.

To enable correct enumeration of outcomes, Table 4b illustrates how the original OUTCOME field shown in Table 4a must first be deconstructed so that the parsed outcome result is specific to the patient referenced by the PATIENT SEQUENCE NUMBER field. Once this has been accomplished, one can correctly sum over 0/1 Outcome Event Indicator variables to obtain accurate outcome event counts as shown in the Correct Totals row.

Table 4b

Configured Outcome Data

As shown in Table 4a, simple enumeration of outcomes without taking the concatenation structure into account can result in greatly inflated totals. Because the proportion of records associated with multiple patients is quite small, failure to account for the sequential stratification of outcomes has only a minimal impact when considering the total cohort of Patient records. However, as demonstrated in Tables 4a and 4b, the potential influence on outcome event totals can be quite sizeable if one happened to examine a small subset in which many of the adverse event reports were linked to multiple patients.

A similar situation occurs with the TREATMENT field. One difference with this field is that unlike the OUTCOME field, the TREATMENT field does not always contain the sequence numbers specified in the MAUDE website instructions. Instead, a simple list of treatments is typically provided, such as “COUMADIN;SYNTHROID;METFORMIN;IRON;FOSAMAX.” Even when present, sequence numbers often do not follow the stated format and instead may be listed in a variety of manners, complicating parsing algorithms, e.g.: “(1) ACCU-CHEK COMPACT METER,;(2) METOPRODOL, (3) CLONIDINE;(4) NORVASC, (5)GLYBURINDE, (6) COUMADIN;(7) LEVAQUIN (8) TRAZADONE;(9) NOTROGLYCERINE;” or “1. COUMADIN;2. SYNTHROID;3. PEPSID;4. CARDIZEM;5. XYLOCAINE;6. LIDOCAINE;7. HEPARIN;”. A final consideration specific to the TREATMENT field involves the presence of semicolons. In some cases, different treatments may be identified using the semicolon as a divider as shown in the example above. However, semicolons may not be present between treatments, e.g., “(3) CLONIDINE;(4) NORVASC, (5)GLYBURINDE, (6) COUMADIN” or may signify line breaks, e.g., “VANCOMYCIN AND GENTAMYCIN AFTER INSERTION OF NEW;GRAFT. ACE INHIBITOR: CATOPRIL 25 MG THREE TIMES;PER DAY” Parsing this last example using semicolons as the divider would lead to the unintended result of three treatments assigned to the patient: i.e., 1. VANCOMYCIN AND GENTAMYCIN AFTER INSERTION OF NEW 2. GRAFT. ACE INHIBITOR: CATOPRIL 25 MG THREE TIMES, and 3. PER DAY.

Based on experience, the TREATMENT field is best evaluated through the application of text-based tools, for example finding records that match the name of a particular medication or therapy of interest. Regardless of the approach taken to summarize treatment data, one must maintain awareness of the same sequential concatenation of results that was described for the OUTCOME field when multiple patients are associated with a MAUDE report.

Text Data

Text data is provided for the vast majority of MAUDE reports, though information may range from a single character to detailed narrative descriptions. The majority of records do not include date information.

Linking to Other MAUDE Files

Text file data is uniquely identified by the MDR TEXT KEY field or the combination of MDR REPORT KEY, PATIENT SEQUENCE NUMBER and TEXT TYPE CODE. In order to link the Text data to other files, one must utilize, the MDR REPORT KEY and also the PATIENT SEQUENCE NUMBER if linking to the Patient file.

Technical Tips and Considerations

The Text file contains more than twice the number of records present in the Master Event file. This occurs for three reasons:

There are n=Master Event file NUMBER PATIENT IN EVENT Text file records for each MDR REPORT KEY. Fortunately unlike the Patient file data, each Text file record is specific to the referenced PATIENT SEQUENCE NUMBER and does not reflect a concatenation of information across patients. Fewer than 0.1% of MAUDE reports have Text file records relating to multiple patients, and the text for a given TEXT TYPE CODE is typically the same or very similar across patient records sharing a common MDR REPORT KEY.

MDR REPORT KEYs may be repeated within the Text file, reflecting the submission of supplemental or additional information for approximately 10 percent of reports.

The most influential factor contributing to the much larger number of Text file records is this file is populated from three separate MedWatch Form 3500 fields (B3, H3 and H10), with each comprising a separate record identified by its TEXT TYPE CODE (Supplemental Table 2). In practical terms, few records are associated with the H3, Manufacturer’s device evaluation information, field, and information from this field is not provided in the detailed report obtained through the MAUDE online search interfaces. Even when populated, text in the H3 field typically points back to information in the H10 field or indicates only that an investigation is pending or in process.

Supplemental Table 2

Types of Text Information Included in the MAUDE Text File

TEXT TYPE CODE	MEDWATCH FORM 3500 FIELD		PERCENTAGE (THRU 2013)
D	B5 =	Adverse event description	50%
E	H3 =	Manufacturer’s device evaluation information	<1%
N	H10 =	Manufacturer’s additional adverse event narrative	49%

Our work with the MAUDE database entails text mining, and it would be highly useful to be able to easily order narrative data about a particularly product problem sequentially by time. However, DATE REPORT is missing for 75 percent of Text file records and when populated contains a small number of records with illogical dates extending back to 1900. Although one might assume that MDR TEXT KEY could be used as a surrogate for the sequential ordering of information relating to a particular report, examination of the narrative data demonstrates this, unfortunately is not always the case (Supplemental Table 3).

Device Problems and Problem Code Descriptions

Data Availability

Approximately one-third of MAUDE reports have one or more reported DEVICE PROBLEM CODEs. However, a quarter of these are not informative (e.g., assigned codes equating to “No Information”, “Not applicable”, “No code available”). A small proportion (< 10 percent) of the specified DEVICE PROBLEM CODEs do not map to a PROBLEM DESCRIPTION provided in the Problem Code Descriptions file. The majority of these missing description codes may be resolved by mapping them to Component or Patient Codes available from the FDA [45].

Figure 7 shows the relationship between the Device Problems and Problem Code Description files. The Device Problems file may be joined to the other files using MDR REPORT KEY, while the Problem Code Description file must be accessed through the Device Problems file via linkage on the DEVICE PROBLEM CODE field.

Figure 7

Device Problem and Problem Code Description File Mapping

In this example the codes associated with the first MDR REPORT KEY (169409) refer to an implantable cardioverter defibrillator device, and those associated to the second MDR REPORT KEY (184584) pertain to a saline breast prosthesis.

It may be useful to transpose the Device Problem file data from long to wide on MDR REPORT KEY prior to joining it with the other MAUDE files in order to link multiple problem codes with a single MAUDE report.

Similar to the discussion of the PRODUCT CODE field in the Device file, the DEVICE PROBLEM CODE field is not verified upon entry and report submitters can mistakenly enter problem codes pertaining to products other than the one being reported.

MAUDE Data Availability Summary

The availability of data may drive or limit questions of interest. Supplemental Figure 1 provides a graphical representation of the amount of shared, non-missing data contained in the MAUDE Device, Patient, Text and Device Problems/Problem Codes files, considering the Master Event file as the universal record. The absence of Device Problems/Problem Code information imposes the largest constraint on data availability. Device Problem information is available for just 32 percent of records. Accordingly if a research question depends upon coded problems, this will greatly limit the available data. In some cases, creative solutions may be useful, such as data mining the Text file information in order to identify product problems when DEVICE PROBLEM CODEs are not provided. In others, it may be necessary to restructure a question of interest or pursue another line of reasoning. The proportions in Supplemental Figure 1 should also be considered ‘best case’ scenarios since even though a record may exist in a file, it may not be populated with information specific to a particular inquiry. For example, while a Patient file record exists for most of the Master Event records (i.e., the same MDR REPORT KEY occurs in both files), outcome or treatment information is present for only 71 percent of the Patient file records and only 26 percent include both. Similarly, even among those records in which a DEVICE PROBLEM CODE is populated, the actual code is not informative for a sizeable proportion of reports.

Lessons Learned Summary

Table 5 summarizes some of the key lessons learned while working with the downloadable MAUDE data files, categorized by area.

Table 5

Key Lessons and Tips for Success When Working with MAUDE Data Files

ISSUE			SUGGESTION
1.	Access	The MAUDE search engines are convenient, but restrict records by time and count and provide only a small subset of available fields.	Use the downloadable MAUDE files to avoid these constraints.
2.	Import	Not all of the MAUDE files include a header row containing field names.	When importing data, make sure your import process starts on the correct line.
3.	Import	Some records contain nonprinting characters or utilize double quotes to indicate missing information.	Account for these idiosyncrasies in the file import process to avoid errors.
4.	Data Availability	MAUDE files or fields may not be populated for some/many reports.	Consider data availability when contemplating research studies using MAUDE data.
5.	Linking	MDR REPORT KEY alone may not be sufficient when linking files.	Incorporate additional key fields when linking Patient, Device or Text file information.
6.	Adverse Even Enumeration	Consider the desired denominator (reports or events) when combining files.	The EVENT KEY field in the Master Event file must be incorporated if enumerating unique events.
7.	Field Structure	Don’t assume the data will always match the format prescribed on the MAUDE website.	In particular, Patient OUTCOME and TREATMENT fields must be handled with care.

Many research inquiries, including our own, require the use of two or more of the individual MAUDE files. In order to combine files appropriately, one must appreciate the data structures underlying the files. The information provided on the MAUDE website is sometimes incomplete or inaccurate, making this process difficult; however, individuals who proceed without understanding the structural nuances of the different MAUDE file types could easily obtain misleading results. For example, failure to incorporate the Master Event file EVENT KEY information, even if the main parameters of interest are contained solely in the Device, Patient, Text or Device Problems files, could result in reporting of the count of unique MAUDE reports, rather than unique events. Similarly, without appreciating the structure of the data files, it can be easy to miscount records as there are more than twice as many Text file observations as MAUDE reports, and perhaps less obvious because the raw numbers are closer, there are more Patient and Device file records than MAUDE reports since a report may be associated with multiple patients or products. If not recognized, these and other issues have the potential to bias conclusions drawn from the MAUDE database.

Conclusion

MAUDE is a valuable database for anyone interested in exploring questions about medical device safety. While the MAUDE search interfaces are useful for extracting records specific to very targeted queries, more complex questions necessitate the use of comprehensive data files provided by the FDA. When we first began working with the MAUDE files, we greatly underestimated the time required to understand the structural complexities of the various MAUDE file types. However, through this work we developed and documented a much deeper understanding of the MAUDE data and its limitations. To our knowledge, this is the first paper to detail the challenges of, and provide solutions for, using the MAUDE database files. The information in this paper would have greatly expedited our use of this resource, and we hope the lessons we learned along the way will prove useful to others and allow more effective use of MAUDE data.

Supplemental Table 3

MDR Text Key Does Not Provide Time Sequential Ordering

MDR REPORT KEY	MDR TEXT KEY	DATE REPORT	TEXT TYPE CODE	TEXT
2280212	11975421	Missing	D	ADDITIONAL INFORMATION INDICATES THAT ADDITIONAL PRODUCT TROUBLESHOOTING WAS PERFORMED DURING A REVISION PROCEDURE AND A 1.1 JOULE COMMANDED SHOCK WAS DELIVERED AND AN OPEN CIRCUIT ERROR MESSAGE WAS DISPLAYED. SUBSEQUENTLY THIS PATIENT'S RV LEAD WAS SURGICALLY CAPPED AND THIS CRT-D WAS EXPLANTED AND REPLACED DUE TO THE REPORTED PRODUCT PERFORMANCE ISSUE.
2280212	12745131	Missing	D	BOSTON SCIENTIFIC RECEIVED INFORMATION THAT THIS RIGHT VENTRICULAR (RV) LEAD HAD EXHIBITED AN ACUTE INCREASE IN SHOCKING IMPEDANCES GREATER THAN 125 OHMS. THE SYSTEM WAS TESTED IN ALL CONFIGURATIONS AND ALL MEASUREMENTS WERE OUT OF RANGE. THERE WAS NO NOISE ON THE SHOCK EGRAM AND THERE WERE NO EVENTS WITH THERAPY IN THE LOGBOOK SINCE IMPLANT PRIOR TO THE THIS FINDING THE IMPEDANCES HAD BEEN CONSISTENTLY IN THE 40'S. BOSTON SCIENTIFIC TECHNICAL SERVICES (TS) DISCUSSED TROUBLESHOOTING. NO ADVERSE PATIENT EFFECTS HAVE BEEN REPORTED.
2280212	13467791	Missing	D	ADDITIONAL INFORMATION INDICATES THAT AN X-RAY WAS PERFORMED AND NO FRACTURE WAS OBSERVED. THE CAUSE FOR THE HIGH IMPEDANCE MEASUREMENTS ARE UNKNOWN AT THIS TIME. THE PATIENT WAS TO UNDERGO A REPLACEMENT PROCEDURE IN THE FUTURE.

This example illustrates that MDR Text Key is not a viable candidate for sequentially ordering in time narrative information received about a product problem.