Complaint reader

A complaint file is written to close a complaint. A CAPA is written to close a CAPA. Neither is written to show a pattern across years, models, and sites; that is the work this skill does. The product is a single table in which every complaint, report, service record, and CAPA for the device is a row with the same fields, so that a series becomes visible and every row can be opened and checked.

The output must be usable by both sides of a matter. It states what the manufacturer's own records say, in the manufacturer's own categories first, and only then adds a neutral classification so records written by different people in different years can be compared. It does not say whether the manufacturer should have acted; it shows what was recorded, when, and what followed.

1. Inputs

• The records. Complaint files (intake form, investigation, reportability decision, reply to the complainant, closure); MDRs (Form 3500A or electronic equivalents, with supplements); MAUDE exports when the user supplies them; service and repair records; CAPAs; trend reports and management-review minutes that discuss the failure mode. Use the case-brief archive (index.csv, text with === PAGE n === markers) if it exists; otherwise build it the same way first.
• The device: model, sister models the manufacturer treats as one platform, software versions, the component or failure mode of interest, and the event date in the matter.
• The manufacturer's procedures, if produced: complaint handling (ISO 13485 8.2.2; 21 CFR 820.35(a); former 820.198), MDR decision procedure (21 CFR 803), CAPA procedure (ISO 13485 8.5.2–8.5.3; former 820.100). Their codes and definitions are the first classification; your neutral codes are the second.

2. One row per record

Write complaints.csv with these columns. Every non-empty cell has a source (ID p.N); use a parallel *_src column or put the source in brackets inside the cell, consistently.

Identity: record id · record type (complaint / MDR / MAUDE / service / CAPA / trend) · manufacturer ref (complaint number, MDR report number, CAPA number) · source doc · model · serial or lot · software version · site (hospital or customer, as named) · country

Dates: event date · received date · aware date (803.3) · investigation closed · reportability decision date · MDR filed date · closed date

What happened, as the manufacturer wrote it: manufacturer failure code · manufacturer description (verbatim, short) · patient involvement (as coded) · patient effect (as written) · stated root cause · stated action · reportability decision (reportable / not reportable / undecided) · reportability reason (verbatim)

Neutral classification (yours, added after reading, codes defined once in codes.md): failure mode · component or subsystem · use phase (setup / use / maintenance / storage) · patient effect class (none / intervention / injury / death / unknown) · root cause class (design / manufacturing / software / use / service / unknown / not investigated) · action class (none / unit repaired / replaced / software fix / labeling / bulletin / field action / design change)

Links: series id · linked complaints · linked MDR · linked CAPA · linked field action · note

Rules for filling the row: - Verbatim fields are quoted short and exact; do not paraphrase a stated root cause. - A field the record does not contain is empty, not "unknown"; unknown is a classification code you assign only after reading the whole record. - When a record covers several events (a trend report, a CAPA), give it its own row and link the events to it; do not split it into invented events. - A MAUDE record and a manufacturer's complaint for the same event are two rows, linked; MAUDE text is redacted and often differs from the file.

3. Find the series

A series is a set of records that share a failure mode and a component (and, when relevant, a software version or a lot range), across any models the manufacturer itself treats as one platform.

1. Sort by failure mode + component, then by event date.
2. For each candidate group, read the descriptions again; records coded differently by the manufacturer often describe the same thing in different words (a "display froze" and a "no response to touch" may be one mode). Record the merge decision and its reason in codes.md.
3. Assign a series id and write series.csv: series id · failure mode · component · models · versions / lots · first event date · first received date · count by year · patient effect classes seen · MDRs filed · CAPAs · field actions · first design or labeling change · sources.
4. Note what the manufacturer's own trend reports say about the series, with citation, and whether the series appears in management review minutes.

Counts are facts about the records produced, not about the field. Always write "in the produced records" and give the production's date range and Bates range; the user must not read a count as an incidence rate. Never compute a rate per device-year unless the user supplies the installed base from a produced document and asks for it.

4. Reconcile complaints and MDRs

For each complaint row with patient involvement or a patient effect, or with a malfunction that the manufacturer's own procedure lists as reportable:

• Find the MDR (by complaint number, by event date and site, by description). Link it or record no MDR found with the search terms in the note.
• Compare the dates: aware date → MDR filed date against 30 calendar days (or 5 working days when 803.53 applies). Write the interval; write cannot tell when either date is missing.
• Compare the texts: event description, patient outcome, device problem codes, and the manufacturer's narrative (H.10) against the complaint file. Record differences as quotations, side by side, in mdr-reconciliation.csv: complaint ref · MDR ref · aware date · filed date · interval (days) · limit · within · difference in description · difference in outcome · difference in cause · sources.
• For not reportable decisions, quote the reason and note the procedure clause the decision cites (or that it cites none).

For MAUDE exports, do the reverse: for each MAUDE report, find the manufacturer complaint; a report without a produced complaint file is a gap to list in section 6.

5. Link the CAPAs

For each CAPA that touches the failure mode or component:

• Record opening date, trigger (the complaints or events it cites, linked by ref), problem statement (verbatim), investigation, root cause (verbatim), corrective and preventive actions, implementation dates, effectiveness check (method, date, criterion, result), closure date.
• Link the complaints that preceded it (the trigger and any earlier ones for the same series that it does not cite), and the complaints that followed its closure. Write capa-links.csv: CAPA ref · opened · closed · series id · complaints cited by CAPA · earlier complaints in series not cited · complaints after closure · effectiveness check · result · sources.
• Where the CAPA produced a design change, a software release, or a labeling change, record the change and its date in the row and in the series table.

Do not write that the CAPA "failed" or "worked"; write the effectiveness criterion the CAPA set, its result, and the count of later complaints in the series, with citations.

6. Write the output

1. complaints.csv, series.csv, mdr-reconciliation.csv, capa-links.csv, codes.md (your classification codes, each defined in one line, with the merge decisions), query-log.csv.
2. complaint-summary.md:
3. Scope: records read, categories, date range, Bates range, and what was not readable (OCR needed, redacted).
4. The series: one short paragraph per series, in time order of first event — first event, first received, how often per year in the produced records, patient effects seen, what the manufacturer called it, what actions followed and when. Every sentence cited.
5. The series around the event in the matter: the records closest to the matter's model, version, failure mode, and date, before and after it.
6. Reporting: the reconciliation table, then the rows with no MDR found and the rows outside the limit, each with its sources and the search terms used.
7. CAPAs: the link table; for each CAPA the effectiveness criterion, result, and later complaints.
8. Gaps: complaint numbers referenced but not produced; MDRs without complaint files; CAPAs cited in trend reports but not produced; service records that mention a prior visit not in the production. Written as requests the team can serve.
9. Sources.

Citation form, everywhere: [D-0042 p.7] or the Bates number; MAUDE report numbers as the export gives them.

7. Rules

• Originals untouched; work on the archive copy.
• Manufacturer's codes first, verbatim; your codes second, defined in codes.md.
• Counts are counts of produced records; say so every time.
• Empty means the record does not say it; unknown means you read it and it does not resolve.
• No statements about what the manufacturer should have done, should have known, or should have reported. The tables show what was recorded and when, what was filed and when, and what followed. Counsel and the retained expert draw the inferences.
• Keep the search log; "no MDR found" is only a finding when the log shows the search.