# Prior authorization recipe

> Build a payer-specific authorization workflow with evidence provenance, explicit submission coverage, status tracking, and review gates.

Source: [https://genhealth.ai/docs/workflows/recipes/prior-authorization](https://genhealth.ai/docs/workflows/recipes/prior-authorization)

## Establish coverage before designing a submission

Record the payer, plan, medical versus pharmacy benefit, service codes, submission channel, supported integration, credentials, and who is permitted to approve submission. Discover the exact available actions and connection status in the authenticated catalog. There is no universal public submit action covering every payer. In particular, carelon_submit_prior_auth is excluded from the public Developer API; a portal logo or preview action is not submission coverage.

## Build the workflow in segments

| Segment | Inputs and outputs to establish | Gate |
| --- | --- | --- |
| Discover requirements | Patient coverage, service/date, payer requirement result and source | Distinguish not-required from unknown or failed lookup |
| Prepare clinical evidence | Organization-owned documents, policy identifier/version, criteria and source citations | Missing or conflicting evidence goes to review |
| Assemble packet | Payer-specific required fields and supporting documents | Validate completeness; do not fabricate missing clinical information |
| Submit | Exact discovered public handler and permitted configured connection | If unavailable, stop at a reviewed packet and hand off; do not invent a portal action |
| Track | Payer reference, pending/approved/denied/needs-information state, required next action | Handle requests for additional information without duplicating the submission |
| Write back | Authorization number, approved units/dates, related order identifier | Verify the resulting record and preserve the audit trail |

## FHIR interoperability is a separate integration contract

CRD discovers requirements, DTR exchanges documentation requirements, and PAS supports authorization exchange. Read the existing FHIR integration overview, then confirm the deployed implementation-guide versions, payer endpoints, authentication, profiles, attachment support, and test environment for your integration. The generic Workflow Developer API does not itself promise that every payer supports these operations. Do not infer conformance from a product-page claim.

- [FHIR integration overview](https://docs.genhealth.ai/docs/integration-with-hl7-davinci-fhir-apis): Existing CRD, DTR, and PAS background; confirm integration-specific contracts before implementation.
- [Run recovery](https://genhealth.ai/docs/workflows/operations.md): Submission timeouts need reconciliation before another external write.

## Define an observable acceptance test

Test not-required, complete submission, missing evidence, request-for-information, denial, approval, and uncertain submission outcome separately. Measure packet completeness, successful submission, approval, and touchless completion separately. A static audit or completed workflow is not evidence of payer approval. Use an authorized payer test environment or an approved operational trial to verify the complete result.