Recurring care and renewals recipe
Build recurring specialty care workflows around current eligibility, service timing, documentation renewal, and duplicate prevention.
Establish the specialty policy and data contracts
Identify the service or product, CPT/HCPCS codes, payer, plan, last encounter or fulfillment, permitted frequency/quantity, required clinical documentation, and target EHR or billing system. Discover candidate, eligibility, timing, documentation, order, and notification actions; inspect every live contract before wiring fields. The organization must provide applicable payer rules and configured connections. Examples include therapy visit renewals, infusion authorization renewals, imaging follow-up, and DME replenishment. This is a workflow design recipe; each specialty needs its own verified policy and action contracts.
| Step | Decision | Exception path |
|---|---|---|
| Find candidates | Select orders/patients within an explicit date window | Missing last encounter/fulfillment or unclear identity goes to review |
| Recheck coverage | Confirm current eligibility and plan changes | Inactive, unknown, or failed coverage lookup blocks the next service or fulfillment |
| Evaluate timing | Apply the current payer/service interval and quantity policy | Not due waits; unknown rules require review |
| Check documentation | Verify prescription and payer-required certification/renewal evidence | Expired or missing evidence triggers a configured renewal process |
| Prevent duplicates | Check an existing equivalent order and persist a logical-cycle checkpoint | Uncertain prior write requires reconciliation |
| Create and verify | Create the permitted order, record vendor ID, and verify expected state | Business failure blocks downstream fulfillment |
A run key is not an order-level duplicate guarantee
An idempotency_key deduplicates one exact run request. Different runs can still target the same patient and recurring service cycle. Use a durable organization-scoped cycle record and the connected system’s supported duplicate checks. Do not automatically retry an order action whose contract says retry_safe=false. Build schedules using supported schedule nodes; a top-level trigger.type=schedule does not configure scheduling.
Test the boundaries
Test due and not-due cases, coverage changes, expired documentation, an existing order, overlapping scheduled runs, and a timeout after order submission. Confirm the exact resulting order, visit, or authorization and its state in the connected system. Start with synthetic data and configured test credentials, then a deliberately bounded approved operational scope.