Audits → Theft / Loss Reporting (DEA Form 106)

Purpose

Record a theft or significant loss of controlled substances in CS Logbook — the incident, the affected substances, and your investigation — when substances are stolen, lost, diverted, or otherwise unaccounted for. What you record here is your internal record and the substrate for the DEA Form 106; the official notification and Form 106 are filed with the DEA, not through CS Logbook.

This is general product information about CS Logbook, not legal advice. CS Logbook does not notify the DEA, file Form 106, or define the reporting timeline. Verify the current requirement on the DEA Theft/Loss Reporting page and with your state board.

Where the requirement lives: the DEA's theft/loss notification and Form 106 rules are in the DEA theft/loss reporting rules and related notification requirements. File via the DEA Theft/Loss Reporting page or the online TLR system. Follow the DEA's stated timeline and process — not this guide — for when and how to report.

When to use it

• A controlled-substance container is missing during a count — biennial, spot check, or transition between shifts. If reconciliation fails, file Form 106.
• A container shows tampering — broken seal, altered label, weight inconsistent with system balance. Photo, secure, file.
• A container is stolen (clinic break-in, vehicle break-in, mobile-vet truck theft) — file 106 + a police report; the report number is captured in the filing.
• A patient or staff diversion is suspected or confirmed — the diversion case is a different scope (HR, legal), but the controlled-substance accountability piece is a 106 filing.
• A "significant loss" is identified — the DEA does not define "significant" with a hard numeric threshold; consult the DEA's guidance, and when unsure, many clinics err toward filing. Under-filing is the riskier failure mode.

The DEA sets the reporting timeline and measures it from discovery (not the incident date) — confirm the current window on the DEA Theft/Loss Reporting page. CS Logbook timestamps both the discovery date and the incident date so your record is unambiguous; keep them clearly distinct. For example, if a container last reconciled Friday evening is found missing Monday morning, the discovery date is Monday — the DEA's window runs from there.

Walkthrough

The theft/loss feature has one route that surfaces a tabbed interface:

/audits/theft-loss   → list of all incidents + create-incident dialog launcher
                      Tabs: All Incidents / Pending DEA Notifications
                      Per-incident detail surface for affected substances + investigation tracker

Step 1 — Open theft-loss reporting

Navigate to /home/<your-clinic>/audits/theft-loss. The page shows two tabs:

• All Incidents — every theft/loss record, sorted by incident_date descending
• Pending DEA Notifications — incidents where dea_report_date IS NULL (the 106 hasn't been confirmed-filed yet); a pending-count alert at the top of the page surfaces this number

Screenshot of the theft-loss landing page (with tabs + pending-notification alert) coming in a 15d-2 follow-up.

If there are pending notifications, the alert is amber and visible at the top: "N incident(s) require DEA notification".

Step 2 — Click Report Incident → fill the Form 106 wizard

Click Report Incident in the top-right. The Form 106 wizard opens as a dialog with sections for incident details, affected substances, police-report info, and investigation notes.

The Incident Details section captures:

• Incident type — theft / loss / diversion / burglary / robbery / other. Pick the closest category; the inspector cares about the underlying facts more than the label.
• Incident date — when the theft/loss happened (or your best estimate). ISO datetime.
• Discovery date — when the loss was discovered. Must be ≥ incident date (the Zod schema enforces this; the form rejects with "Discovery date cannot be before incident date" otherwise).
• Location — where the loss occurred (e.g., "Surgery suite controlled-substance safe", "Mobile vet truck VIN 12345"). Required.
• Circumstances — narrative of what happened, what was checked, what's known. Min 10 chars; aim for paragraphs of detail, not single sentences. This text becomes the Form 106's "circumstances" field.

If law enforcement has been involved:

• Police report number — optional; capture as soon as the police agency provides it
• Police agency — optional; e.g., "Springfield Police Department"

Click Submit. The action inserts a row into theft_loss_incidents with investigation_status='reported' and dea_report_date=NULL (filing pending).

Step 3 — Add affected substances

After the incident is created, navigate to the incident detail (click the row in the All Incidents tab). The Affected Substances card lets you add each container with a quantity-lost.

For each affected substance:

• Container — pick from the autocomplete; only active (non-disposed) containers in your account
• Quantity lost — must be > 0. Decimal precision matches the substance unit.
• Unit — auto-filled from the container's substance; verify it matches your physical measurement

Screenshot of the affected-substances list with the add-substance form expanded coming in a 15d-2 follow-up.

A theft_loss_items row is inserted for each affected substance + container. The substance_details_snapshot column captures a JSON snapshot (substance name + schedule + NDC + container number) so the record is preserved even if the underlying substance/container is later edited or soft-deleted.

Step 4 — Track the investigation (followups + witnesses)

The Investigation Tracker card on the incident detail page surfaces tabs for the ongoing investigation:

• Followups tab — every action taken in the investigation:
  • Followup type — dea_contact / police_update / investigation_finding / recovery / other
  • Description — what was done, what was found
  • Action date — when (ISO date format YYYY-MM-DD)
• Witnesses tab — every witness statement:
  • Witness name — required
  • Contact info — optional (phone, email — for follow-up access)
  • Statement — required, min 10 chars

Use the followup log generously — every recount, every conversation with the police, every internal interview is a row. The detail builds an investigation chronology that becomes the Form 106 supporting documentation.

Step 5 — Notify the DEA

On the DEA's timeline (which it measures from discovery — verify the current window with the DEA), file the DEA Form 106. The CS Logbook UI does not transmit to the DEA — the filing happens on the DEA Theft/Loss Reporting page / online TLR system (or by phone to your local Diversion office; the online form is preferred for the audit trail).

After you submit the 106 to the DEA, return to the incident detail in CS Logbook and use Notify DEA to capture the filing metadata:

• Notification method — phone / online / fax / in_person. The online portal is the standard.
• Notification date — when you submitted the 106 (ISO datetime). This becomes dea_report_date on the incident row.
• Confirmation number — the DEA portal returns a confirmation number on submission; capture it
• Notes — anything else worth preserving (e.g., "Dr. Reed submitted from clinic safe terminal at 14:23 EST")

Screenshot of the Notify DEA form with the 4 fields and submit button coming in a 15d-2 follow-up.

The action inserts a row into theft_loss_notifications and updates theft_loss_incidents.dea_report_date. The incident drops out of the Pending DEA Notifications tab.

Step 6 — Resolve the incident

When the investigation concludes, update the incident:

• Investigation status — under_investigation → resolved or closed
• Resolution notes — what concluded the investigation (e.g., "Located in vendor return shipment 2026-04-30; police report withdrawn", or "Theft confirmed; staff member terminated; HR matter closed; no recovery")

The incident remains visible (it's never deleted — DEA expects audit-trail integrity per its record-retention rules) but moves out of active follow-up.

Step 7 — Cross-reference findings to a DEA prep audit

If the next DEA inspection asks about theft/loss filings, the inspector will work through Category 5 of the DEA prep audit checklist. Each filed Form 106 surfaces here; the linked investigation timeline + DEA confirmation number + resolution notes form the complete record.

The unified Discrepancies & CAPAs queue at /audits/discrepancies also surfaces theft/loss-linked CAPAs (auto-created when an incident has corrective_action_required flagged on resolution).

Field reference

Create-incident form

Add-affected-substance form

Add-followup form

Add-witness form

Notify-DEA form

Update-incident form (post-resolution)

Resulting database rows

Edge cases

Discovery date earlier than incident date

The Zod schema enforces discoveryDate >= incidentDate. The form rejects inline. This is a real-world correctness check: you cannot discover something before it happened. If your dates are wrong (you accidentally typed the wrong year on incident date), correct them; the validation isn't a bug.

Incident date unknown

If you have no idea when the loss occurred — e.g., you discovered a container missing during a quarterly count and don't know when it disappeared — set incidentDate to your best estimate (typically the date of the most recent confirmed inventory check) and document the uncertainty in investigationNotes. The DEA expects the timeline to be your best-available reconstruction, not perfect knowledge.

Quantity lost exceeds container balance

The form does not enforce quantityLost <= container balance — but the substance_details_snapshot captures the system balance at filing time so anomalies are surfaced. If you're filing a theft of a container that already had transactions deducting balance, the discrepancy between system balance and quantity-lost is itself a finding worth noting.

"Just under significant" — file or don't file?

Default: file. Over-filing is generally low-risk; under-filing is where exposure lies — but confirm the DEA's own guidance on what must be reported. If a small Schedule II loss makes you nervous, the practical posture is: record it, file with the DEA, document the recovery (if any), and close the loop. Acting promptly within the DEA's window + the audit trail you're creating is the protective posture.

Recovery after filing

If a missing container is later recovered (vendor return, found-in-different-shelf), update the incident with investigation_status='resolved' and a resolution note. Do not delete the incident — the DEA retention obligation runs from the date of the original record, not from any subsequent recovery. The Form 106 stays filed; the recovery is documented in the resolution.

Soft warning: incident not yet DEA-notified, >24 hours since discovery

If dea_report_date IS NULL AND (now() - discovery_date) > 1 business day, the page surfaces a soft amber warning at the top of the Pending DEA Notifications tab: "This incident is past the DEA's 1-business-day notification window." The user can still proceed (the filing happens externally regardless) but the visibility prompts immediate action.

Hard block: deleting an incident with pending DEA notification

There is no UI path to hard-delete a theft_loss_incidents row that has dea_report_date IS NULL. The audit-trail integrity requires that pending-notification records remain visible until they're confirmed-filed (or marked notified-by-other-means). Soft-delete RPCs for theft/loss are deferred per the open NocoDB ticket 4aa5af14.

Common mistakes

• Filing only the CS Logbook record + skipping the DEA portal. CS Logbook captures your record; the DEA Diversion Control Division portal is the actual filing. Both are required.
• Confusing incident date with discovery date. The DEA measures its reporting window from discovery, not from the incident date. Get this wrong and the timeline is wrong.
• Not capturing the police report number. If law enforcement is involved, the police report number is part of the Form 106 record. Capture it on the incident, not in someone's email thread.
• Skipping the followup log. The investigation timeline IS the audit trail. A clinic with one Form 106 filing and no followup log looks suspicious — were you actually investigating?
• Witnesses without statements. A witness name without a statement is a hint, not a record. The DEA inspector wants to see what the witness said, not just who they were.
• Filing under the wrong incident type. If a controlled-substance container disappeared from a locked safe overnight with signs of forced entry, that's burglary, not loss. The wrong category misleads the DEA's classification system. If unsure, default to theft (the most general category that triggers the DEA's reporting window).
• Treating recovery as deletion. If you find the missing container, that's a resolution — not a reason to delete the record. Mark the incident resolved with a resolution note. The DEA retention is per-record, not conditional on outcome.
• Forgetting to capture the DEA confirmation number. The portal returns a confirmation number on submission; if you lose it, the audit trail is missing the proof-of-filing. Capture it via Notify-DEA the moment you receive it.

Related

• Audits — overview — full audit lifecycle and where theft/loss fits
• DEA audit prep — the prep checklist whose Category 5 reviews Form 106 filings
• Inventory → Containers — the entities being reported as lost/stolen
• Discrepancies & CAPA — where post-resolution corrective actions land
• Sprint 16 theft/loss feature plan — internal architecture reference
• Glossary § DEA CFR citations — quick reference to the theft/loss reporting rules
• DEA Theft/Loss Reporting (Form 106) + online TLR system — the official filing channel