> For the complete documentation index, see [llms.txt](https://docs.mdintegrations.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mdintegrations.com/partner/exploring-features/sync-video-consults.md).

# Sync Video Consults

Two unrelated things at MDI both involve "video," and it's easy to conflate them.

### At a glance

<table><thead><tr><th width="228.765625">Term</th><th>What it is</th></tr></thead><tbody><tr><td><strong>AV Video</strong></td><td>A state-compliance artifact: a short recording attached to a patient's profile, satisfying a legal requirement in certain states before a prescription can be issued.</td></tr><tr><td><strong>Sync Video Consult</strong></td><td>An Encounter type: a live, on-demand video call between patient and physician, offered as an alternative to MDI's standard asynchronous, chat-based Encounter.</td></tr></tbody></table>

### AV Video

Some US states require an audio/video interaction between physician and patient before a prescription can be issued. Most states are satisfied by the physician's live interaction during a normal async Encounter — no partner-side work needed.&#x20;

A smaller set of states instead accept a short, pre-recorded intro video: the patient states their name, date of birth, state, and condition, and the file is uploaded and attached to the Patient record via `intro_video_id`.&#x20;

This is documented in full in [State AV/Sync Requirements](/partner/troubleshooting/technical-concepts/state-av-sync-requirements.md), including how to check which states require it (`is_av_flow`) and how to upload the video.

### Sync Video Consult

MDI's default clinical workflow is asynchronous: the patient completes an intake, and a physician reviews and responds whenever they're next available — no scheduling, no live call.&#x20;

A Sync Video Consult is a different Encounter/Case variant: a real-time appointment, closer to a traditional telehealth video visit, where a physician needs to be available at a scheduled time rather than picking the case up on their own schedule. Because it depends on live availability, it has different assignment and reassignment mechanics than a standard async Encounter — a case can't just sit in a queue until someone gets to it.

### Side-by-side comparison

|                           | AV Video                                                         | Sync Video Consult                                  |
| ------------------------- | ---------------------------------------------------------------- | --------------------------------------------------- |
| **Trigger/purpose**       | State legal requirement before prescribing                       | Required for certain clinical protocols             |
| **Timing**                | Asynchronous — recorded once, reviewed later                     | Synchronous — live, scheduled call                  |
| **Who's involved**        | Patient records alone; physician reviews later                   | Patient and physician, live, at the same time       |
| **What it produces**      | A compliance artifact attached to the Patient (`intro_video_id`) | A completed live visit within a Sync Encounter/Case |
| **Where it's configured** | Files API + `intro_video_id`; state check via `is_av_flow`       | Not fully documented — confirm with MDI             |

If you're building for a state with an AV requirement, that's a Patient-level compliance step, not a scheduling decision. If you're building a live telehealth flow, that's a distinct Encounter type, not a compliance workaround. Don't assume support for one implies support for the other.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.mdintegrations.com/partner/exploring-features/sync-video-consults.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.