Audit Trail
What it does
Every time DOSE writes a record to RxClaim, it creates a complete audit entry that links the RxClaim change back to the exact upstream request that caused it.
Without DOSE, RxClaim only knows that a change came from CATAPP or RXAPIHUB — there is no way to trace which application, which work order, or which user initiated it.
With DOSE, the full chain is traceable: RxClaim change → which DOSE record → which file upload → which upstream application → which work order → which user.
What is captured per record
For every call made to RxClaim, DOSE records:
| What | Why |
|---|---|
| Which record in which file | Links the RxClaim change to the source upload |
| Which RxClaim environment was targeted | Multi-environment routing visibility |
| The full request sent | Reproducibility and debugging |
| The full response received | Including any rejection reasons from RxClaim |
| How long the call took | Performance monitoring |
| The outcome | Success, rejected by RxClaim, network failure, rate-limited |
| Which retry attempt this was | Retry history for the record |
How audit records are linked
Every audit entry carries an upload ID and record ID. Following those links gives the full chain from the RxClaim change to the original business request.
Data retention
All audit data is retained for 90 days, after which it is automatically deleted. This is a compliance decision — the 90-day window is enforced at the database level, not in application code.
Technical reference
| Detail | Value |
|---|---|
| Collection | DeliveryAuditLog (MongoDB Atlas) |
| Entity class | DeliveryAuditLogEntity |
| Retention | 90 days (TTL on requestedAt field) |
| Outcome values | Success, Retryable, Permanent, Circuit Open, Rate Limited |
| Write pattern | Batch insert after each processing batch completes |