DoseSpot fired eRxSent at 20:06 UTC for two prescriptions to pharmacy DoseSpot 46622. Per DoseSpot's own definition, that status means the pharmacy's system returned an initial Success ack — the message had reached its destination. A second confirmation (PharmacyVerified) didn't fire until 6–7 hours later. The patient called during that gap; an agent had the provider re‑send at 22:38 UTC, and that pair was both transmitted and second‑confirmed in one second. Net result: the patient now has two live copies of each drug at the same pharmacy.
Provider opens a new prescription in DoseSpot's embedded UI. A draft row is created on DoseSpot's side — no transmission yet.
Webhook · PrescriptionStatusUpdate → MEDvidi inserts a `prescriptions` row + first `prescription_logs` entry
Any subsequent change to the draft (dose, pharmacy, sig). Can loop multiple times. Still nothing on the wire.
Webhook · PrescriptionStatusUpdate / MedicationStatusUpdate with `previous → new` deltas
Provider clicks "Approve & Send." DoseSpot moves the Rx into the signing queue. For controlled substances (Schedule II–V) this is where EPCS two-factor signing happens.
Webhook · PrescriptionStatusUpdate · EpcsSigned (code 11) fires here for controlled substances
DoseSpot is in the act of transmitting. A brief transient state — the prescription has left DoseSpot and is in flight on the Surescripts network as an NCPDP SCRIPT NewRx message.
Wire · DoseSpot → Surescripts → pharmacy's NCPDP endpoint
DoseSpot's own definition: "the message has successfully reached its destination and we have received an initial Success status from the recipient's system." So the pharmacy's intake system has the NewRx and has acked transport-layer receipt.
Webhook · PrescriptionResult · StatusDetails = "Prescription sent"
DoseSpot's own definition: "a pharmacy or their system confirms that they have received the prescription." A second, downstream confirmation — exact trigger is opaque and varies by pharmacy PMS (internal ingest event, pharmacist action, or batch import). Per DoseSpot: "can happen simultaneously [with eRxSent] or vary depending on the pharmacy's system."
Webhook · PrescriptionResult · StatusDetails = "Prescription delivery verified"
Side branch: transmission failure (invalid pharmacy NPI, NCPDP reject, unsupported drug). DoseSpot reports the failure; the prescription does not reach the pharmacy.
Webhook · PrescriptionResult · status = 6 with error detail
Side branch: provider discards a draft before signing (as happened with batch 2 here — 285212585 / 285212608, both MedicationStatus = Deleted at 22:36 UTC). Nothing was transmitted.
Webhook · MedicationStatusUpdate · medication status = 4
Wrote and signed two prescriptions an hour ago. From their view: job done, DoseSpot accepted the transmission.
Fired eRxSent at 20:06 UTC for both prescriptions — per DoseSpot's own definition, "the message has successfully reached its destination and we have received an initial Success status from the recipient's system." No PharmacyVerified follow-up yet.
The pharmacy's intake system had already returned Success to DoseSpot (that's what eRxSent attests). The second confirmation event (PharmacyVerified) hadn't fired — DoseSpot's docs are deliberately vague about what triggers it, and the pharmacist looking at their dispensing queue may not see the Rx until that second event lands.
Opens a "Prescription issue" task. The CRM Prescription Status column shows the latest event — at this moment, eRxSent, not PharmacyVerified.
Per DoseSpot's documentation: eRxSent = the message reached the pharmacy and the pharmacy's system returned an initial Success ack. PharmacyVerified = "a pharmacy or their system confirms that they have received the prescription" — a deliberately vague secondary confirmation whose trigger varies by pharmacy system. The two can fire simultaneously or hours apart. A patient calling between the two is not a transmission failure; it's the pharmacist's queue not yet showing the Rx that the front-door system already acked.
Both pairs are now PharmacyVerified and medication_status Active at pharmacy 46622. The resolution copy ("Prescription delivered to initial pharmacy") suggests one prescription got through; in reality, two of each are live. A retransmit-before-wait rule, or a hard rule against re-sending while the original is still in the verify window, would prevent this.