The Extent-of-Condition Review That Ate Three Weeks: 312 Device History Records, Four Agents, and a Recall Decision

How fast can your quality department answer "how many did we ship?"

Not roughly. Exactly. With lot numbers, ship dates, consignee names, quantities and the serial of the tool that touched each one. Because on the afternoon your calibration house calls to say the torque driver failed high at its annual check, that is the only question anyone will ask, and the answer decides whether your field action covers six lots or forty-one.

The Afternoon the Calibration Certificate Comes Back Failed

Every device manufacturer has had some version of this. Torque driver SN-2214 was last calibrated on 14 March. On 22 July the annual calibration comes back out of tolerance high — it has been over-torquing. It lives at the final assembly station where the housing screws go into a reusable surgical handpiece.

An extent-of-condition review is the work of answering one question — how many units left the building with the same potential defect — and it decides whether a field action is bounded or blanket. Here the window is everything built between 14 March and 22 July: 41 lots, 312 device history records, roughly 18,400 units, shipped to 63 distributors and hospital accounts.

Nobody can tell you today which of those 41 lots actually used SN-2214, because the driver serial is handwritten on the traveler at station 6, and the traveler is a scanned image in the eQMS.

Why This Job Takes Three Weeks, and It Is Not Because It Is Hard

The work per record is simple. Open the scanned traveler. Find the station 6 block. Read the driver serial and the three in-process torque values. Note the operator initials and date. Check whether that lot had the final pull test that would have caught an over-torqued housing. Note the customer, ship date and quantity. Check for an existing complaint. Type nine fields into a workbook. Next record.

Thirty-five minutes each, honestly measured, once you count crooked scans and the two lots where the traveler was reprinted mid-run. Three hundred and twelve records is 182 hours. Two quality engineers at thirty hours a week makes it three weeks — during which the CAPA queue does not move, the supplier audit is rescheduled again, and the design history file work for the pending submission stops dead.

It takes three weeks for one reason: one person reads one record at a time. The job is not complicated. It is serial.

What Agent Teams Changed

The development that matters here arrived with Claude Opus 4.6 as a research preview called Agent Teams: several assistants split one large job, work at the same time, and their results are merged into one answer. The practical effect for a manufacturer is unglamorous and specific — throughput on batch work that used to be done one item at a time.

This is not the same claim as "it reads faster than a person." One assistant reading 312 records in order is helpful but still a queue. Four working separate lot ranges at once and handing back one merged table is a different shape of day. The calendar effect is what you are buying.

flowchart TD
  A["Torque driver SN-2214 fails annual calibration, 22 July"] --> B["Quality manager bounds it: 41 lots, 312 DHRs"]
  B --> C["Agent 1: lots 4101-4110"]
  B --> D["Agent 2: lots 4111-4120"]
  B --> E["Agent 3: lots 4121-4130"]
  B --> F["Agent 4: lots 4131-4141"]
  C --> G["Merged table: driver serial, torque values, ship date, consignee"]
  D --> G
  E --> G
  F --> G
  G --> H["MRB reviews flagged lots, decides field action scope"]

The Wednesday That Used to Be Three Weeks

Wednesday, 9 a.m. The quality manager writes the extraction rule once, in plain English: per traveler, pull the station 6 driver serial, the three torque readings, operator initials, build dates, whether the final pull test was performed, the lot number, consignee and ship quantity. Flag any record where the serial is SN-2214, illegible, or where a torque reading exceeds the upper specification limit.

The lot range is split four ways and the work runs at the same time. By late morning there is one table with 312 rows and a column for confidence on every handwritten serial.

Now the human part, which has to be done properly. All 47 flagged records are opened and verified against the original scan by a quality engineer, twelve minutes each. Then a random ten percent of the unflagged records — 31 of them — gets the same treatment as a check on the extraction. Sixteen hours of verification across two engineers, finished Thursday afternoon.

Friday morning the material review board sits down with an answer instead of a status update: six lots used SN-2214, two had the final pull test on 100% of units, four did not. The field action is scoped to four lots and 1,740 units — on day three instead of day twenty-two.

The Arithmetic: Days, Held Inventory, and a Field Action You Did Not Have to Over-Scope

Assumptions, illustrative: 312 records at 35 minutes each; quality engineering loaded at $64 an hour; $167,000 of finished goods held across nine lots while the population is unbounded; field action cost of $6,800 per lot covering customer letters, return freight, replacement units and effectiveness checks.

The hours line is worth $10,368 and it is the smallest number on the table. The one that matters is the last row. When you cannot bound the population quickly, the defensible choice is to scope wide — expensive in money and far more expensive in the account relationships you spend the next year repairing. Saying "four lots, here is the evidence, here is the sample verification" on day three is the whole return.

Treat the $251,600 as an illustration, not a promise. Sometimes the answer is "all 41 lots really are affected" and no amount of speed changes that. Speed changes how often you over-scope out of ignorance.

Where Splitting the Job Goes Wrong

Three failure modes to plan for before running this on anything that touches a regulatory file.

Gaps and overlaps in the split. If lot ranges are handed out casually, two assistants can cover the same range and none cover lots 4136 to 4138. The fix is mechanical: number the population first, in one list, and reconcile the merged row count against that list before anyone reads the findings. If the table has 309 rows and your population was 312, stop.

Handwriting. A "4" written by a second-shift operator with a Sharpie in a gowned glove is not always a "4". Insist on a confidence marker per extracted serial and treat anything below threshold as flagged, not as read. This is why the verification sample is not optional.

The judgement at the end. Whether an over-torqued housing on a reusable handpiece is a reportable malfunction under 21 CFR Part 803 is decided by trained people against a written decision tree, with a health hazard evaluation behind it. The merged table is evidence for that conversation, not the conversation. It does not decide whether to notify your FDA district office, and it does not sign the customer letter.

Record what you did. Under ISO 13485 clause 4.1.6 software used in the quality system is validated for its intended use, and an investigator who sees a 312-record review finished in three days will ask how. Have ready a validated method description, the reconciliation record and the sample verification results.

Frequently asked questions

Does finishing the review faster change my 30-day MDR clock?

No, and it matters not to believe otherwise. The reporting clock under 21 CFR Part 803 runs from the day your company becomes aware of information reasonably suggesting a reportable event — not from the day your review finishes. What speed buys is different: bounding the affected population, completing the health hazard evaluation, and deciding on a field action while you still have options, rather than telling the agency you do not yet know how many units are out there.

How do I stop four assistants from missing a lot between them?

Build the population list first as a numbered file — 312 rows, one per record — and treat it as the master. Split by row ranges from that file, never by "whatever is in the folder". When results come back, the first thing anyone checks is whether every row number appears exactly once. Five minutes, and it catches the one failure that would genuinely embarrass you in front of a notified body.

Can I use the same approach for the annual management review?

Yes, and it is a gentler place to start than a live investigation. Complaint trending, a year of nonconformance categorisation, supplier performance summaries and the post-market surveillance inputs required under ISO 13485 clause 8.2.1 are all large repetitive reads with no clock on them. Run it there first, compare against last year's manually prepared review, and you will learn where the extraction is weak before it matters.

What does this cost to run?

Far less than most owners assume — running these tools has come down roughly tenfold since 2025, and for a job this size the running cost is a small fraction of one quality engineer's day. The real cost is setup: writing the extraction rule properly, building the population list, agreeing the verification sample with your quality manager. Budget a day of a senior person's time the first time, a couple of hours after that.

Start With a Review You Have Already Done

Do not test this on a live investigation. Take an extent-of-condition review your team finished last year, where you already know the answer, and run it again. Compare the merged table to what your engineers found by hand, and where it disagrees, find out why. That costs an afternoon and it is the evidence you point at when someone asks whether you trust it.

A last point: the week you scope a field action, the phone does not stop. Distributors, hospital materials managers and sales reps call at once, and every one of those calls has to be captured properly, because some of them are complaints. CallSphere builds voice and chat agents that answer immediately, take the account, device model and lot number accurately, and route anything alleging a device problem to the quality on-call instead of a voicemail box. It has no opinion about your torque readings. It keeps calls from being lost while your engineers are heads-down on the records.