A device case turns on dates. The record holds them, but they are scattered across files written by different people, in different departments, who were not thinking about each other.
This guide shows how to collect those dates into one timeline with four streams, where each date comes from, what it can and cannot prove, and which patterns in a finished timeline deserve a closer look. The four-stream figure is on page 5 and the table form on page 8.
Who this guide is for
- Legal counsel who must show what a manufacturer knew at a given date, or show that it did not.
- Engineering experts who connect design changes, complaints, and the unit in question.
- Risk managers who reconstruct an incident for an internal review or a claim.
This guide is general technical information. It is not legal advice. Reporting periods are quoted from the regulation in force in October 2026; check the text that applied on the dates in question.
01The timeline comes first
The question in most device matters is not only what happened, but when each party knew it. A complaint received before a design change means one thing; the same complaint received after it means another. A warning added to the instructions is a different fact depending on whether the first injury came before or after the revision.
Memory does not hold these dates reliably, and a production of fifty thousand pages does not present them in order. The timeline is the tool that does. It is usually the first thing an engineering expert builds, and the document that decides which records are worth reading closely.
Three rules keep it honest.
One line per dated fact. An entry is a date, an event, and a source. Opinions and summaries go elsewhere.
Every line has a source. The document and its page or identifier. A line without a source is a note, not evidence.
Separate the dates a document carries. The date an event happened, the date it was recorded, the date the record was approved, and the date it was produced are four different dates. Write down which one you used.
A timeline built this way serves both sides. It shows knowledge where the record shows it, and it shows silence where the record is silent. Both are findings.
An illustrative timeline, not a real device. Reading down a date column connects the streams: here the sensor change order and the new warning both follow the first complaints, and the unit was serviced between them. Each such alignment is a question for the record, not an answer.
02Where the dates are
Each stream has its own records and its own kind of date. The list below says which documents carry a date worth a line, and which date on the document to take.
Design stream
From the design and development file (guide 05): the design plan and its revisions; the approval of design inputs; the design reviews; the dates of verification and validation reports, and of any retest; design transfer; and every design change order, with the date it was opened, approved, and effective in production.
Take the approval date as the date the manufacturer committed to the content. Keep the author's date in the notes. A test report approved a year after the test was run carries both dates, and the gap is itself a line.
Market stream
The premarket submission and the clearance or approval letter; each revision of the labeling and the instructions for use, with the change record; marketing claims that changed; and any field notice, bulletin, or letter to users.
For labeling, the effective date and the date the revised text first shipped with a unit are rarely the same. Ask for both.
Field stream
Complaints, by the date received (21 CFR 820.35(a) requires it) and the date of the event complained of; MDRs, by the date the manufacturer became aware and the date it reported; CAPAs, by the dates opened, root cause assigned, actions completed, effectiveness checked, and closed; corrections and removals, by the decision date and the report date.
The regulation sets clocks that make the gaps readable: a manufacturer reports a death, serious injury, or reportable malfunction within thirty calendar days of becoming aware (21 CFR 803.50), within five work days where remedial action is needed to prevent an unreasonable risk (803.53), and reports a correction or removal within ten working days of starting it (806.10).
Unit stream
For the device in question: the build date and lot from the production record; shipment and installation; each service event, with the parts replaced and the software version after service; the event itself; and the preservation steps, from tagging to the first examination.
The unit stream is the one that is usually built from the facility's records, not the manufacturer's. Match it to the other three by serial number and software version, not by model name.
A document's production date, the Bates number, and its position in a folder say nothing about when it was written. Order by the dates on the face of the document, and check them against the metadata where the file is native.
03Building it
The timeline is a table before it is a figure. Keep it in one file, one row per line, and generate the figure from it. These columns keep it usable at five hundred rows.
Date, and which date
One column for the date, one for its type: event, received, approved, effective, produced. Use ISO format and record the time zone where the hour matters.
Stream
Design, market, field, or unit. A line can belong to only one stream; a connection between streams is a note, not a line.
Source
Document title, revision, and page or Bates range. For data exports, the file name and the row. For testimony, the transcript page and line.
Certainty
Three levels: dated on its face; inferred from other records; stated from memory. The figure shows only the first two.
Gaps
A period with no entries in a stream is a line too: "no complaint records produced, 2019–2021". Silence that is not written down is forgotten.
04Reading it
A finished timeline is read down the date column, across the streams. The alignments below most often deserve a closer look. Each is a question for the record, and the record may answer it either way.
A change follows the complaints
A design change, a software release, or a new warning that comes after a run of similar complaints asks what the change was for. The change order's stated reason is the first place to look.
A CAPA closes before its data
A CAPA closed as "no trend" while complaints continue, or closed before the effectiveness check was due, asks what the closure was based on.
The risk file stands still
Complaints and MDRs accumulate, but the risk management file keeps its original date. ISO 14971 requires production and post-production information to feed back into it.
Reports arrive late
An MDR filed well outside the thirty-day clock, or a correction reported outside ten working days, asks when awareness really began, and who decided.
The unit was touched
Service on the unit between the complaints and the event, especially a replaced board or a software update, asks what the service was for and what version it left behind.
The streams are silent together
A period where nothing is produced in any stream usually means a records gap, not a quiet year. Ask for the index of each file for that period.
05Common mistakes
Most weak timelines fail in the same ways. These are the ones we see most often.
Built from memory first
A timeline written from interviews and then "confirmed" by the record keeps the interview's errors.
One stream only
A field-only timeline shows complaints without the design decisions that answer them.
Document date as knowledge date
A report dated the day it was approved was known to its authors weeks before. Carry both.
Model name as identity
Two units of one model with different software versions have different histories.
Stopping at the event
What the manufacturer did after the event often says what it thought the problem was.
Mixing clocks
Device, server, and facility clocks differ. Record each offset once (guide 07).
✓Timeline at a glance
- One table, one row per dated fact, one file
- Date type recorded for every row (event, received, approved, effective, produced)
- Stream assigned to every row: design, market, field, unit
- Source with page or identifier on every row
- Certainty level on every row; memory-only rows marked
- Design change orders entered with opened, approved, and effective dates
- Labeling revisions entered with effective and first-shipped dates
- Complaints entered by date received and date of event
- MDR and 806 reports entered with awareness and report dates; clocks checked
- Unit built, shipped, serviced, and preserved, by serial and software version
- Gaps written down as rows
- Figure generated from the table, not drawn by hand
§Sources and further reading
- eCFR — 21 CFR 803.50 and 803.53 (manufacturer reporting periods); 806.10 (corrections and removals)ecfr.gov
- eCFR — 21 CFR 820.35, Control of records (complaint and servicing records)ecfr.gov
- ISO 14971:2019 — Application of risk management to medical devices (clause 10, production and post-production)iso.org
A–ZTerms used in this guide
- Timeline
- A single dated list of events from every stream of the record, each with its source, used to show what was known and when.
- Stream
- One source of dated events: design, market, field, or the unit itself. Each has its own records and its own clocks.
- Document date
- The date on a document, as approved or issued. Often later than the date its contents were known.
- Knowledge date
- The earliest date the record shows that someone knew a fact. Carried beside the document date.
- Awareness date
- The date a manufacturer first learned of a reportable event, from which the MDR reporting period runs.
- Clock offset
- The difference between two clocks: device, server, facility, or wall time. Recorded once per clock, applied to every entry.
- Alignment
- Two dated events from different streams placed side by side on the timeline, so that their order and interval can be read.
- Source
- The document, page, log entry, or record that supports each date on the timeline. A date without one is not evidence.