# Provider workflows across specialties

> Build provider operations around shared workflow primitives, specialty-specific requirements, and discovered EHR, payer, and billing connections.

Source: [https://genhealth.ai/docs/workflows/provider-workflows](https://genhealth.ai/docs/workflows/provider-workflows)

## Start with the provider operation

GenHealth workflows combine document processing, system actions, decisions, review, and run tracking. Use the same authoring lifecycle for primary care, specialty groups, outpatient services, and other provider operations. Specialties supply different clinical requirements, payer policies, service codes, and destination systems. Discover the actual supported actions and configured connections for each workflow; a specialty label is not a coverage guarantee.

| Provider operation | Specialty examples to scope | Contracts to establish |
| --- | --- | --- |
| Referral and patient intake | Primary care referrals, specialty consultations, imaging orders, therapy referrals | Referral fields, verified patient identity, destination EHR, missing-information route |
| Financial clearance | Visits, procedures, diagnostics, infusion services | Current coverage, benefit details, service codes, authorization requirements |
| Prior authorization | Imaging, surgery, specialty drugs, rehabilitation services | Payer/benefit coverage, clinical evidence, supported submission channel, status/writeback |
| Recurring care and renewals | Therapy visit renewals, recurring infusions, follow-up services, supply replenishment | Service frequency, prior utilization, current eligibility, documentation expiry, duplicate prevention |
| Revenue cycle follow-up | Claim status, missing documentation, denial resolution | Claim identifiers, reason codes, permitted corrective action, verified resulting state |

## Choose an adapter using live discovery

Use list_workflow_integrations, search_workflow_actions, get_workflow_action, and list_workflow_integration_connections. The catalog includes system-specific actions; API, portal, and organization configuration can differ. Map vendor IDs explicitly and check business outcomes before the next write. Reviewed descriptions and selected output types are currently available for targeted athenahealth and Brightree patient actions; other actions can still have partial or unknown schemas.

- [Build and run your first workflow](https://genhealth.ai/docs/workflows/agent-quickstart.md): A specialty-neutral synthetic execution test using REST or MCP.
- [Provider patient intake](https://genhealth.ai/docs/workflows/recipes/patient-intake.md): A common intake design with a labeled Brightree adapter example.
- [athenahealth chart context example](https://genhealth.ai/docs/examples/provider-chart-context.json): Importable read-only vendor operation for a verified athenahealth patient ID. Requires a configured connection; review endpoints are annotations.
- [Prior authorization](https://genhealth.ai/docs/workflows/recipes/prior-authorization.md): Plan payer-specific evidence, submission coverage, status, and review.
- [Recurring care and renewals](https://genhealth.ai/docs/workflows/recipes/recurring-care.md): Apply specialty rules before another order, visit, or authorization.

## Run the athenahealth example

Validate and import the chart-context JSON using the lifecycle in the quickstart. Supply trigger_data={"patient_id":"<VERIFIED_ATHENAHEALTH_PATIENT_ID>"} with a new run key. The graph reads chart context, checks success, and routes errors to a review annotation. It creates no Patient Case or note. The patient_id is a vendor identifier, not a local GenHealth UUID. Verify the resulting chart context within your authorized environment before adding downstream actions.