# Recurring care and renewals recipe

> Build recurring specialty care workflows around current eligibility, service timing, documentation renewal, and duplicate prevention.

Source: [https://genhealth.ai/docs/workflows/recipes/recurring-care](https://genhealth.ai/docs/workflows/recipes/recurring-care)

## 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.