Provider workflows across specialties
Build provider operations around shared workflow primitives, specialty-specific requirements, and discovered EHR, payer, and billing connections.
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.
A specialty-neutral synthetic execution test using REST or MCP.
Explore Provider patient intakeA common intake design with a labeled Brightree adapter example.
Explore athenahealth chart context exampleImportable read-only vendor operation for a verified athenahealth patient ID. Requires a configured connection; review endpoints are annotations.
Explore Prior authorizationPlan payer-specific evidence, submission coverage, status, and review.
Explore Recurring care and renewalsApply specialty rules before another order, visit, or authorization.
ExploreRun 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.