Device timeline

In a device matter the question is almost never "what failed"; it is "who knew what, and when". A single timeline cannot answer it, because the device, the field, the unit, and the case move on different clocks. This skill builds four parallel streams on one time axis, then lays them side by side so the team can see, for any date, what the manufacturer's own records show it knew.

Every entry has a citation to a document and a page, and two dates: the date the event happened or the document is dated, and the date the record shows the manufacturer (or the hospital, or the plaintiff) knew of it. The gap between the two is often the case.

1. Inputs

• The archive. If the case-brief skill has run, use its index.csv and the extracted text files with === PAGE n === markers. If not, build the archive the same way first (one text file per document, page markers, an index with a category per document). Never build a timeline from file names or from memory of a document; read the page.
• The device identity: manufacturer, model, catalog number, software version, serial or lot number, and the date of the event. Confirm them from a produced record and cite it; the timeline is pinned to this device, not to the model in general.
• The period. Default: from the first design record to today. Narrow it only when the user asks.
• Which clocks matter. In the United States: 21 CFR 803 (MDR: 30 calendar days from becoming aware; 5 working days when remedial action is needed to prevent an unreasonable risk of substantial harm); 21 CFR 806 (correction or removal report within 10 working days of initiating); CAPA timeliness under the manufacturer's own procedure (ISO 13485 8.5.2; former 21 CFR 820.100); the manufacturer's own complaint-handling procedure for the time to investigate and to make a reportability decision. Read the procedure if it was produced; its deadlines are the ones the manufacturer promised to meet.

2. The four streams

Build each stream as a CSV with the same columns, so they can be merged:

stream · date · date type (exact / month / year / before / after / between) · knowledge date · event · actor · source (ID and page) · confidence (stated / inferred / disputed) · clock · note

Stream A — the device (model level) Design and development plan; user needs and inputs; design reviews; verification and validation; design transfer; each software release and its release notes, known anomalies, and problem reports; each design change with its impact assessment and letter to file; each premarket submission and FDA decision; each labeling and IFU revision; each risk file revision; standards editions claimed at each point.

Stream B — the field (model level) Each complaint for the failure mode (date received, date of event, source, investigation closed, reportability decision); each MDR filed (event date, aware date, report date, type); each service bulletin and field-repair instruction; each CAPA (opened, root cause, actions, effectiveness check, closed); each field action (decision, FDA notification, customer notice, completion); trend analyses and management reviews that mention the failure mode. Include sister models when a produced document treats them as the same platform.

Stream C — the unit (this serial or lot) Manufacture and release (DHR); shipment and installation; acceptance and commissioning tests; every preventive maintenance and service visit; every software update applied; every error log entry and alarm in the period around the event; the event itself and the actions after it (reset, repair, return, inspection, destructive test); custody changes.

Stream D — the case Incident report and hospital investigation; notice to the manufacturer; complaint filed; answers and motions; discovery served and responses; protective orders; each production wave with its Bates range; each deposition with date and witness; expert deadlines; inspection dates and protocols; trial setting.

3. Extract

Work stream by stream, document category by document category, from the index. For each entry:

1. Read the page. Record the date as the document gives it and set date type. A document that says "in Q2 2023" is between with both bounds; "prior to release" is before with the release date as the bound. Do not sharpen a vague date.
2. Set the knowledge date: the earliest date a produced record shows the actor knew of the event. For a complaint, it is the date received, not the date of the event. For a design problem, it is the date of the first problem report, test failure, or review minute that names it. When no record shows it, leave the field empty — never fill it with the event date.
3. Record the actor as the document names it (a department, a role, a named person); do not generalize "a service engineer" to "the manufacturer".
4. Set confidence: stated when the document says it; inferred when you combine two documents (say which two in the note); disputed when two documents give different dates (enter both lines and cross-reference them).
5. Set clock when a regulatory or procedural clock starts or ends on this entry: MDR-aware, MDR-filed, 806-initiated, 806-reported, CAPA-open, CAPA-due, CAPA-closed, complaint-received, complaint-closed.

Keep a query-log.csv of the search terms used per stream. The absence of an entry is only meaningful if the log shows the search was made.

4. Check the clocks

After extraction, pair the clock entries and compute the interval in the unit the rule uses (calendar days for 803; working days for the 5-day MDR and for 806; whatever the procedure says for CAPA and complaints). Write clocks.csv: clock · start event · start date · start source · end event · end date · end source · interval · limit · within limit (yes / no / cannot tell) · note.

Rules for this step: - A clock without both ends is cannot tell. Do not infer a filing date from the absence of a filing. - The aware date for an MDR is the date any employee became aware of information that reasonably suggests a reportable event (803.3); use the earliest receipt date a record shows, and say in the note which record. - For 806, the clock starts when the correction or removal is initiated, not when it is decided; cite the document that shows initiation. - Record the limit as the rule or procedure states it, with its citation; when the manufacturer's procedure is stricter than the regulation, use the procedure and note both. - Working-day counts use the manufacturer's country calendar for its clocks and the court's for the case stream; say which you used.

5. Merge and write

1. timeline.csv — all four streams merged and sorted by date (then knowledge date). Keep the stream column; the team filters it.
2. timeline.md — the readable version, in sections:
3. Device identity (one table, every cell cited).
4. The four streams side by side: a table with one row per month (or per day around the event), four columns A–D, each cell holding the entries with citations. Empty cells are informative; keep them.
5. The knowledge gaps: for each field event that bears on the failure mode, the event date, the knowledge date, the gap, and the design or labeling change (if any) that followed and when, every item cited.
6. The clocks: clocks.csv as a table, with the cannot tell rows kept and explained.
7. Disputed dates: every disputed pair with both sources.
8. What is not in the record: dated events the documents refer to but do not produce (a review that minutes mention, a report a CAPA cites), with the reference cited, written as requests the team can serve.
9. Sources and search log.
10. Optionally timeline.svg or a PNG: four horizontal bands, one per stream, events as ticks with short labels, the event date as a vertical line across all four, the clock intervals as bars with their limit marked. Generate it from timeline.csv with a short script (matplotlib or plain SVG), so a change in the data redraws it. A drawn timeline that is not generated from the CSV goes stale and is not trusted.

Citation form, everywhere: [D-0042 p.7], [Depo Lastname 112:4–113:2], Bates number when there is one.

6. Refreshing

When a new production or deposition arrives, index it, extract its entries into the streams with the new source IDs, re-sort, recompute the clocks, and regenerate the figure. Add a short What changed section at the top of timeline.md: entries added, dates that moved, clocks whose status changed. Never edit a dated entry in place without a new source; add the new line and mark the pair disputed if they differ.

7. Rules

• Originals untouched; work on the archive copy.
• Two dates per entry; an empty knowledge date is an honest answer, a guessed one is not.
• Vague dates stay vague (date type), and the figure draws them as ranges.
• A clock with one end is cannot tell.
• No conclusions about intent or negligence. The timeline shows what the records say happened and when the records show each actor knew it. Counsel and the retained expert draw the inferences.
• Keep the search log; it is the evidence that silence in the record is real.