> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scan.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Referral pre-production checklist

> Test referral creation in the Scan.com sandbox, collect evidence that each referral was received, and submit the checklist for production review.

Use this checklist when your integration is ready to move from the sandbox
toward production. This first version covers the core
[`POST /api/v2/referrals`](https://docs.scan.com/api-reference/referrals/creates-a-referral) flow.
It does not certify scheduling, webhooks, reports, payments, or a
line-of-business-specific workflow.

Use synthetic patient data in the sandbox. Do not put protected health
information in the workbook or in the email you send to Scan.

> [card] Download the referral checklist
>
> Excel workbook — referral submission tests, evidence fields, and handoff instructions

[Open](https://docs.scan.com/downloads/scan-com-referral-pre-production-checklist.xlsx)

## How to complete it

The **Referral submission** sheet has three columns:

| Column | What to record |
| - | - |
| Test | The scenario and evidence fields to capture |
| Did Scan.com receive? | `Yes`, `No`, or `N/A`, plus any short verification note |
| Did partner system receive? | `Yes`, `No`, or `N/A`, plus any short verification note |

Every workbook field is optional. Leave a field blank or enter `N/A` when a
scenario is outside your contracted modalities or integration scope. This does
not make required API request fields optional; the create-referral contract
still determines what each request must contain.

For each test you run:

1. Submit the referral to `https://api.staging.scan.com`.
2. Save the `X-Request-Id` response header. On an error, the same value is in
   the response body as `request_id`.
3. Save the returned `referral_id` and the `patient_id` used or created.
4. Confirm Scan received the referral by fetching it with
   [`GET /api/v2/referrals/{referral_id}`](https://docs.scan.com/api-reference/referrals/returns-a-referral-by-id).
5. Confirm your system stored or processed the response and identifiers.
6. Add your own downstream reference when one exists.

## Suggested test coverage

The workbook includes common scenarios so one file can work across partners:

* Existing `patient_id` and nested `patient` submission
* Patient identity and contact information
* Readable physician order PDF
* MRI and CT with and without contrast
* X-ray with laterality or views where applicable
* Multiple orders in one visit
* Multiple visits in one referral

Only run scenarios covered by your contract and implementation. Mark the rest
`N/A`. Use a real `cpt_code_id` returned by the sandbox
[CPT code endpoint](https://docs.scan.com/api-reference/cpt-codes/returns-cpt-code-mappings.md) rather
than copying an example UUID from the documentation.

## Evidence to include

The **Test** cell provides space for:

* `X-Request-Id` or error `request_id`
* `referral_id`
* `patient_id`
* Your partner-system reference
* A brief note about the procedure or expected behavior

Do not paste bearer tokens, full request bodies, order PDFs, or patient details
into the workbook.

## Submit for review

Review the workbook for secrets or patient information, then email the completed
file to [api@scan.com](mailto:api@scan.com). Include your organization name,
the sandbox account you tested, and the production scope you want Scan to
review.

Scan may ask for additional tests when your production scope includes workers'
compensation, partner-driven scheduling, webhooks, reports, payments, or other
capabilities beyond referral submission.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.