This is a ready-to-use log for tracking DSCSA and EPCIS data exceptions, the technical and data-quality failures that are common at volume and are not, by themselves, evidence about product legitimacy. Keeping this log separate from the suspect and illegitimate product investigation record does two things: it stops routine connectivity noise from diluting a patient-safety investigation log, and it makes chronic trading-partner or platform problems visible as a trend, not just a string of one-off tickets. Replace every <<FILL: ...>> placeholder. A filled specimen follows. This content is educational and general, not legal or regulatory advice.
Document control header
| Field | Entry |
|---|---|
| Document title | DSCSA Exception and Data Discrepancy Log |
| Document number | <<FILL: LOG-ID, e.g. LOG-SC-027>> |
| Version | <<FILL: version>> |
| Owner | <<FILL: role, e.g. Trade Compliance Manager>> |
| Parent SOP | <<FILL: suspect/illegitimate product SOP ID, for the escalation path>> |
| Review cadence | <<FILL: e.g. weekly entry review, monthly trend review>> |
| Retention | <<FILL: period, generally aligned to the 6-year DSCSA record period>> |
When to use this log versus the suspect-product investigation record
Log an entry here for any EPCIS or verification event that does not reconcile cleanly. Most entries close as a data exception and never leave this log. An entry is escalated to the suspect and illegitimate product investigation record, per <<FILL: SOP-ID>>, only when the cause cannot be explained and reproduced as an internal or trading-partner data or IT problem, or when an independent physical or transactional red flag is present alongside it. Record the triage decision here either way, and cross-reference the investigation number when one is opened.
Field definitions
| Field | Format | Required | Who | When |
|---|---|---|---|---|
| Entry ID | text | Yes | Logger | On detection |
| Date / time detected | YYYY-MM-DD HH:MM | Yes | Logger | On detection |
| Connection / trading partner | text | Yes | Logger | On detection |
| Product / NDC / lot (if applicable) | text | No | Logger | On detection |
| Exception category | schema failure / VRS timeout / GLN mismatch / aggregation mismatch / late transmission / duplicate event / other | Yes | Logger | On detection |
| Description | free text | Yes | Logger | On detection |
| Triage decision | data exception / suspect-product trigger | Yes | Logger, reviewed by QA or trade compliance | At triage |
| Cause identified | free text (mapping error, outage, known lag, unexplained) | Yes | Investigator | At resolution |
| Escalated to investigation | investigation number or “No” | Yes | Trade compliance / QA | If escalated |
| Resolution | free text | Yes | Investigator | At closure |
| Closure date | YYYY-MM-DD | Yes | Reviewer | At closure |
Log
| Entry ID | Date/time | Connection | Category | Description | Triage | Escalated | Resolution | Closed |
|---|---|---|---|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
Monthly trend review
Perform this review on the cadence in the header, even in a month with no entries; a zero-entry month is itself recorded, not omitted.
| Field | Entry |
|---|---|
| Review period | <<FILL: from>> to <<FILL: to>> |
| Total entries | <<FILL>> |
| By category | <<FILL: count per category>> |
| By connection / trading partner | <<FILL: count per partner, flag any partner with a rising count>> |
| Escalated to suspect-product investigation | <<FILL: count and investigation numbers>> |
| Recurring or unresolved pattern identified | <<FILL: e.g. one partner's connection producing repeated late-transmission entries>> |
| Action arising | <<FILL: e.g. change control on a mapping fix, a conversation with the partner, an EPCIS version review>> |
| Reviewed by (name, date) | <<FILL>> |
Acceptance criteria
- Every EPCIS or verification event that does not reconcile has an entry, whether or not it is escalated.
- The triage decision and its rationale are recorded for every entry, not just the escalated ones.
- No entry sits open past
<<FILL: target closure time, e.g. 5 business days>>without an assigned owner and a documented reason. - The monthly trend review identifies recurring patterns by connection and by category, and every identified pattern has a stated action or a documented reason none was needed.
- Escalated entries cross-reference the investigation number, and closed suspect-product investigations that originated here are traceable back to their log entry.
References
DSCSA, section 582 of the Federal Food, Drug, and Cosmetic Act (21 U.S.C. 360eee-1); suspect/illegitimate product provisions. GS1 EPCIS and CBV standards (message and vocabulary conformance, the source of most schema-level exceptions). FDA guidance on DSCSA suspect and illegitimate product identification and notification.
Confirm the current statute and guidance before issue.
Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
Filled specimen
A week of illustrative entries for a wholesale distributor’s serialization program, followed by the trend review that catches the pattern a single entry would not show.
| Entry ID | Date/time | Connection | Category | Description | Triage | Escalated | Resolution | Closed |
|---|---|---|---|---|---|---|---|---|
| EXC-2026-0301 | 2026-08-11 09:14 | Manufacturer B (AS2) | Late transmission | T3/EPCIS for shipment SH-88213 arrived 6 hours after physical receipt | Data exception | No | Known lag on Manufacturer B’s batch AS2 window; no product impact, product held pending data per WI | 2026-08-11 |
| EXC-2026-0302 | 2026-08-12 14:02 | Manufacturer B (AS2) | Late transmission | T3/EPCIS for shipment SH-88240 arrived 5.5 hours after physical receipt | Data exception | No | Same known cause as EXC-2026-0301 | 2026-08-12 |
| EXC-2026-0303 | 2026-08-13 10:40 | VRS network | VRS timeout | Verification request on a saleable return timed out after 15 seconds, 2 retries | Data exception | No | Responder maintenance window confirmed with manufacturer; unit quarantined per WI pending retry, retried successfully next business day | 2026-08-14 |
| EXC-2026-0304 | 2026-08-14 11:55 | Manufacturer B (AS2) | Late transmission | T3/EPCIS for shipment SH-88266 arrived 7 hours after physical receipt | Data exception | No | Same cause, third occurrence in the week | 2026-08-14 |
| EXC-2026-0305 | 2026-08-15 16:20 | VRS network | VRS invalid | Verification on a saleable return returned explicit invalid, not a timeout | Suspect-product trigger | Yes, SIP-2026-021 | Escalated per SOP; see suspect-product investigation record | Open, tracked in SIP-2026-021 |
Trend review, August 2026:
| Field | Entry |
|---|---|
| Total entries | 5 |
| By category | Late transmission: 3, VRS timeout: 1, VRS invalid: 1 |
| By connection | Manufacturer B: 3 (all late transmission), VRS network: 2 |
| Escalated | 1 (EXC-2026-0305, SIP-2026-021) |
| Pattern identified | Three late-transmission entries from Manufacturer B in one week, each individually triaged as a data exception with no product impact, but the recurrence itself is the signal: this is a chronic connection issue, not three unrelated events. |
| Action arising | Raised with Manufacturer B’s trade compliance contact; requested either a shorter batch window or a move to a faster transport. Tracked as a partner-connection improvement item, not a deviation, since no product was affected. Re-review in 30 days to confirm the pattern resolves. |
| Reviewed by | M. Duarte, Trade Compliance, 02 Sep 2026 |
What this specimen teaches: none of the three late-transmission entries individually looked worth escalating, and each was correctly triaged as a data exception on its own. It was the trend review, not any single entry, that turned three shrugged-off events into an action against the partner connection. That is exactly what a log separate from the investigation record is for.
Common inspection findings this log prevents
- No record exists of EPCIS or verification exceptions that did not rise to a suspect-product investigation, so the program cannot show it tracks or trends its own data quality.
- A pattern of the same connection or partner producing repeated exceptions was never surfaced because each one was closed individually with no trend review.
- Every technical exception was escalated to the suspect-product SOP by default, producing an inflated investigation count that obscures the real patient-safety signals inside it.
- An exception that should have been escalated (an explicit invalid verification, not a timeout) was logged and closed here without ever reaching the suspect-product workflow.
- Zero-entry periods are simply not recorded, so it cannot be shown the exception process was running at all during that period.
How to adapt this log
- Set your document number, owner, cadence, and parent SOP in the header.
- Add categories specific to your platform (for example a specific EPCIS field validation your system flags) alongside the generic ones.
- Tie the escalation field directly to your suspect/illegitimate product SOP’s investigation numbering so the two records cross-reference cleanly.
- Feed the monthly trend review into your supplier or trading-partner performance review, not just an internal file, so a chronic partner-side problem becomes visible where it can actually be fixed.
- Confirm the current statute and guidance referenced before issue.