Add Status, Pharmacist Worklists, and Digests to Prior Authorization

Extend an existing prior-authorization platform with status lookup, pharmacist worklists, and an end-of-workday digest email. The existing platform sits between a pharmacy and an insurance payer. When it receives a payer message indicating that prior authorization is required, the platform creates a prior-authorization record, selects the payer's form, and uses AI to fill it from available patient records. A pharmacist reviews and may edit the form, approves submission, and the platform sends it to the payer. The payer responds asynchronously with approval, denial, or a request for more information, which may require resubmission. ### Requirements and Constraints - The users of these new features are pharmacists. - The platform creates the prior-authorization record; a pharmacist does not create it manually through these features. - The platform serves 100 pharmacy or health-system organizations, with 100 pharmacists per organization. - Each pharmacist works on about 10 prior authorizations per day. - A completed prior-authorization PDF may be as large as 50 MB. - Authentication and authorization are supplied by an existing service and are outside the design scope. - The existing form-generation and submission workflow is already built. Extend it without redesigning its AI functionality. ### Part 1 — Retrieve Current Status Provide a way for a pharmacist to retrieve a prior authorization's status and receive reliable updates from the asynchronous payer response path. #### What This Part Should Cover - A durable status model linked to the prior authorization and its submission attempts. - An external-response ingestion path with correlation, duplicate handling, and an approach to delayed or out-of-order responses. - A read path that distinguishes current status, update time, and any pending request for more information. ### Part 2 — Add to a Pharmacist's Worklist Allow a pharmacist to add a prior authorization to their worklist, similar to assigning a ticket to themselves. #### What This Part Should Cover - A worklist data model and an idempotent add operation within the existing organization and user authorization context. - Clarification of whether one authorization can be on multiple pharmacists' worklists or must have one exclusive assignee. - Pagination, filtering, and concurrent assignment behavior for the selected ownership rule. ### Part 3 — Send an End-of-Workday Digest At the end of each pharmacist's workday, send an email listing worklist items that have changed meaningfully or are stale because they have had no update for a day. #### What This Part Should Cover - Definitions of a meaningful change, the stale interval, and the pharmacist's workday boundary and time zone. - A durable record of which changes were considered for each digest and which messages were sent. - Reliable email scheduling and retry behavior that handles changes occurring while a digest is being generated. ```hint Keep activity and relevance separate A repeated delivery of the same payer message can be recent activity without being a meaningful change. Decide which timestamp controls stale detection and which events belong in the digest. ``` ### What a Strong Answer Covers The three features share consistent prior-authorization identities, submission versions, and organization boundaries. Status changes feed worklists and digests through durable state. The design preserves the asynchronous payer workflow, handles large PDFs separately from small status records, and explains capacity using the supplied workload without treating daily work touches as necessarily distinct new authorizations. ### Follow-up Questions 1. How would you handle a response to an older submission after a pharmacist has sent a revised form? 2. What happens if two pharmacists add the same authorization at nearly the same time? 3. If an email provider accepts a digest but the sender times out before receiving the acknowledgment, how would you recover without falsely claiming guaranteed exactly-once delivery?