Manufacturer and User Facility Device Experience (MAUDE)
Updated 08/28/13

Record count, main table: 2,879,232

MAUDE: Manufacturer and User Facility Device Experience Database (Maintained by the U.S. Food and Drug Administration's Center for Devices and Radiological Health (CDRH)).        

SUMMARY:
    The MAUDE dataset includes information about problems that occurred with medical devices. The problems include injuries, deaths and/or product malfunctions. 
    The data comes from two forms: Medwatch 3500 and 3500A. Health officials use form 3500 to voluntarily report adverse events. User facilities (hospitals, clinics etc.), product distributors and manufacturers are also required to report problems through Medwatch 3500A.
    The data consists of all voluntary reports since June 1993, user facility reports since 1991, distributor reports since 1993, and manufacturer reports since August 1996.
    The data starts at differing years, in part, because of different reporting regulations. According to the CDRH, new regulations were enacted in the early 1990s to help curb under-reporting. These regulations require reporting from user-facilities and distributors. 
    Before 1992, this database was known as Medical Device Reports, or MDR. This database had mandatory reports from manufacturers and voluntary reports from others. NICAR has MDR reports dating to 1984 and running through the time manufacturer reports began to be entered in the MAUDE database (August 1996).
    Because of MDR and MAUDE's overlapping years, 1991 through August 1996, you will have to acquire both data sets if you want to have a full picture of the device malfunction reports from those years.
    Note that the update date includes all events received by the FDA by that date and not necessarily all events that have occurred by that date.
    One major limitation of MAUDE is that it has no location information. In other words, you won't be able to track which medical facilities in your area report the most device problems. This apparently is done to encourage reporting by protecting the identity of the hospitals. The same apparently is true for certain information submitted by manufacturers. 
    Patient-specific data is also removed for privacy reasons.    

THE DATA: 
The dataset should include the following in addition to this Readme:

    TABLES:

       - MAUDE.CSV: The main table. 
        
       - PROD.CSV: Lookup table for the prodcde field in DEVICE.CSV
        
       - PATIENT.CSV: Contains information on the patient(s) involved in the event.

        - DEVICE.CSV: Contains information on the device(s) involved in the event.
       
       - TEXT.CSV: Includes a memo field with a narrative about the problem(s) experienced with the medical device. Split into two files.                  
       
    LAYOUTS:(An excel file called "Record_Layouts.xls" matching the text layout files are also included in this folder).

       - MAUDElay.TXT: Record layout for MAUDE.csv. 

       - PRODlay.TXT: Record layout for PROD.csv       

       - PATIENTlay.TXT: Record layout for PATIENT.csv

       - DEVICElay.TXT: Record layout for DEVICE.csv 

       - TEXTlay.XT: Record layout for TEXT.csv

    LOOKUPS:
    The lookup tables for 2012 have changed. FDA officals said the old lookup tables were no longer relevant. The new lookups include:

    
    -Contact Addresses (_contacts.csv)

    -Establishment Types (_estatyp.csv)

    -Offical Correspondant (_corresp.csv)

    -Listing Establishment (_list_est.csv)

    -Listing propriety name (_prop_nam.csv)
 
    -Registration Listing (_reg_list.csv)

    -Listing PCD (_pcd_exp.csv)

    -US agent (_us_agent.csv)

    -Registration (_regis.csv)

    -Owner Operator (_own_op.csv)
    
    -Device to problem code (_devprob.csv)

    -Problem Code (_probcode.csv)
	
	-Device Operator (_devop.csv)
	
	-Event Location (_evloc.csv)


The device report product code table (DEVICE) links with the Listing PCD table via the product code (prod_code). 
Listing PCD contains an owner operator field that links with the owner operator table (own_op_no). 
The owner operator table contains a registration key (reg_key), which links to the following tables: registration, US agent, official correspondant, registration listing. 
Registration listing links to establishment types by the registration listing ID (listing_id).
The registration key (reg_key) field also links listing establishment types to establishment types. Official contacts links to contact addresses with the field contact ID (contact_ID). 
MAUDE.csv links to the device problem table with the MDR report key (mdrkey). The problem code table in turn links to the device problem table via the problem code field (Prbcode). 
The event location table, which contains codes for the possible places the incident could have occurred, links to the DEVICE table through the field event location (evloc). It should be noted that this information is provided voluntarily, and errors may occur in reference to event locations. The focus of the database is on the device, not the location. 

###   OTHER NOTES   ###
   
In the DEVICE table, a field called DEVAGE (device age) is measured in months, days, or years. For example, one record might say three years and the next will say 36 months. In other cases the value is just a date.

In the MAUDE table, the EVLOC field (event location) has multiple codes for the same location. For example, hospital falls under both 001 and 500. There are also separate codes for different rooms and departments within the hospital.

To the FDA, "establishment" is a broad term: Section 510 of the Federal Food, Drug, and Cosmetic Act (FD&C Act) requires that all establishments engaged in the manufacture, preparation, propagation, compounding, assembly, or processing of medical devices intended for human use and commercial distribution in the United States register their establishments with the Food and Drug Administration (FDA). 

Due to data entry inconsistencies and multiple company names, the registered establishments do not join effectively with manufacturers listed in the other MAUDE tables.  NICAR includes them as a reference for proper names; contact information may be more complete in some cases, compared to contacts listed in old reports. The FDA also offers an online registration lookup at www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfRL/registration.cfm


       FORMS:
       - 3500.pdf and 3500a.pdf: Samples of the MedWatch forms filled out by health professionals, user facilities, distributors and manufacturers.

       - MDRCODE.PDF: Instructions and coding manual for form 3500A -- the mandatory report for user facilities, distributors and manufacturers.

    
The tables and lookups are all in CSV format, which can be easily imported into any database manager program, including Microsoft Access. Here are the directions for Access:
1) Open a blank database in Access, name it and save it. 
2) Inside the new database, go to the "External Data" tab. Select "Text File" on the Import & Link side (all the way to the left). 
Then select "Import." 
4) An import wizard will ask you to locate the file(s), and will then walk you through the necessary steps. In this case, the files are "delimited", the delimiters is a comma; check the box that says "First Row Contains Field Names", and choose " (a double quote) as the text qualifier. Then follow the record layout to choose the appropriate data type for each field. Then click Finish. 
5) Each table will need to be imported separately.

            
ABOUT THE DATA:

    The four tables MAUDE, PATIENT, DEVICE And TEXT  are linked by the MDRREPT (MDR Report Key) field. Linking the tables in this way will give you a detailed account of what happened in each reported event, including information on the patient(s), the device(s), manufacturer as well as a narrative of the problem.

    Though the MDRREPT numbers link the four tables, they operate a little differently within each table, particularly as they relate to the EVKEY (Event Key) in MAUDE.csv and DEVKEY (Device Event Key) in DEVICE.csv.

    In MAUDE.csv, a single EVKEY (event key) may have multiple MDRREPT numbers associated with it. That's because each report on a particular event is given a distinct MDRREPT number while the event has a single number. Thus, there could be five MDRREPT numbers linked to a single event if the manufacturer, user-facility, distributor and two voluntary reporters reported on the same event. Here's an example from the data: EVKEY 226782 appears 11 times in MAUDE.csv. Each time it appears it has a distinct MDRREPT number.

    It works a little differently in DEVICE.csv. Because each device reported is given a distinct number, one MDRREPT can be associated with multiple DEVKEY numbers. Here's an example from the data: MDRREPT number 308527 involves nine devices. In DEVICE.csv there are nine distinct devkey numbers associated with MDRREPT 308527.

    Each patient also has a distinct record in PATIENT.csv. Here's an example from the data: MDRREPT 44812 has one record in MAUDE.csv, but it involves eight patients. All eight of those patients have separate records in PATIENT.csv.

    In TEXT.csv, there may be multiple narrative's linked to a particular event. Each narrative will have a distinct number (TEXTKEY). As you will note on form 3500A, there are three possible places for narrative: sections B5, H3 and H10. 



Straight from the mouth of the CDRH:

    "The basic nugget of reporting in MAUDE is an MDR REPORT.  An MDR REPORT is submitted by one of the recognized report submitter types (user facility, device manufacturer, device distributor, or voluntary reporter) describing a single event.
       "In the case of manufacturers they may submit multiple reports on a single event, but each manufacturer report is about a separate device in the same event.  An event is one where it is believed, or meets the reporting threshold, that a medical device may have malfunctioned or caused or contributed to the death or serious injury of a patient.
     "Each MDR REPORT has one or more devices, one or more patients, and one or more texts.  MDR_REPORT_KEY links the records comprising a complete set of data for a single MDR REPORT. Since there is a reasonable likelihood that more than one report submitter may submit reports about the same event, the EVENT_KEY links all MDR REPORTs that are believed to be reporting the same event.
    "Also, since report submitters other than device manufacturers can submit MDR REPORTs which identify multiple devices, DEVICE_EVENT_KEY links all device information that is believed to pertain to the same single medical device within a single event."

    The different recording methods in each table explain the varying record counts for the tables. Patient.csv and device.csv have more records than maude.csv, given that the patients and devices are aggregated in maude.csv but treated separately in patient.csv and device.csv. Similarly, text.csv has substantially more records than the other three tables, given the multiple narratives that can be attached to a single event.



A WORD OF CAUTION:
    There are at least 86 records in the DEVICE.csv table that do not line up with the correct fields. The problem first appears in the MANSTATE and MANZIP fields. Most of the records with problems show up here. Because of extra delimiters in these records, the city is often listed where the state should be and the state often listed where the zip code should be. To help flag this problem, NICAR made the state field wider to hold the entire city name. We also did this for the PREAMEND field. The 510 number from the NO510 field will show up in the PREAMEND field. If you come across one of these records and would like to double-check it for accuracy, use the MAUDE on-line search at the CDRH Web site: http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfMAUDE/search.CFM 



OTHER NOTES:

    The date the event occurred is not included in this database. Agency officials say they believe it could identify individual patients. There is a similar situation with the event problem code (F10 from 3500A) and manufacturer evaluation codes (H6 from 3500A).

    The number "0" appears more than 39,000 times in the "ndevno" field in maude.csv. CDRH says that apparently reflects wrong information submitted by reporters. If there were "0" devices, obviously, there would be no need to report.

    The "510k" field refers to the Medical Device Act mandating that companies submit a "Premarket Notification" whenever a new device is similar to another already on the market. For example, the 510(k) number might be K991234 - this means it is the 1,234th PMN submission for calendar year 1999.

    The Prodcde field in device.csv contains a 3-digit code. The Center for Devices and Radiological Health said the code is "the product code that's used internally to differentiate different generic product types. That product code is generally tied to a Regulation number that defines just what that product type is. Occasionally there are several product codes associated with a single Regulation number." The product code definitions may be found at www.fda.gov/cdrh/prodcode.html

    Beware that there will be two fields for all "dates" that appear in the data. One is in character format, as it came from the agency, and the other is merely that same date converted to date format by NICAR. The character-formatted field looks on the surface like a date field (with slashes, etc.), however this will be useless when you try to do any ordering or grouping by date because it is character format. Therefore, you need to use the NICAR-converted date fields. 
    


STORIES: 

    What problems occurred with breast implants, hospital beds, or other medical devices? Did that number increase or decrease from previous years? Do certain manufacturers appear much more than others? 
    The MAUDE database provides tips to answer some of these questions. Details include patient reaction, facility information and data about the device itself. Keep in mind that MAUDE includes only reported problems. That doesn't mean if a certain implant type appears a lot in here that it's the "most dangerous." If that type is used four times more than any other, it stands to reason that there would be more reports about it. 
    In a 2002 series, the Star-Ledger (Newark, N.J.) found that, while devices can save lives, recalls of these products are on the rise (Story no. 19846).  Robert Gebelhoff describes the project in the January/February 2003 Uplink.  The Tallahassee Democrat showed that nurses are often blamed for deaths caused by faulty infusion pumps, like the ones that commonly deliver automatic morphine drips (Story no. 17311).   
      Journalists can also apply MAUDE to other aspects of health care.   In "Dangerous Care: Nurses' Hidden Role in Medical Error," The Chicago Tribune revealed that: "overwhelmed and inadequately trained nurses kill and injure hundreds of patients every year as hospitals sacrifice safety for an improved bottom line." See story no. 17136 in the IRE resource center. Reporter Mike Berens used MAUDE data, especially the narrative reports, as a base to help him report the story. For more information on the series, see the reporter's story in the December 2000 issue of "Unlink," published by NICAR, or in the May/June 2000 issue of the "IRE Journal." 
    The IRE Resource Center offers an online search of archived "Uplink" and "IRE Journal" indexes. It also has several print and broadcast stories involving medical device problems as well as a reporter tipsheet. Search the Resource Center holdings at http://www.ire.org/resourcecenter/. To order stories and tipsheets, contact the IRE Resource Center at (573) 882-3364.
    


WHO TO CALL WITH QUESTIONS

FDA Contact: Howard Press, (240) 276-3457
CDRH contact: Phone: 240-276-0111

NICAR Data Library: (573) 884-7711

General information on MAUDE and FDA regulatory information can be found on the Center for 
Devices and Radiological Health website: www.fda.gov/cdrh/index.html