> 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/troubleshooting/technical-concepts/state-av-sync-requirements.md).

# State AV/Sync Requirements

US telehealth law is not uniform: some states require some form of audio/video ("AV") interaction between the physician and the patient before a prescription can be issued. MDI handles this requirement two different ways depending on the state, and which one applies affects what — if anything — you need to build.

## Live states

Most states with an AV requirement are satisfied by a live interaction. In these states, the physician assigned to the Encounter handles the audio/video requirement directly as part of their review, so there's no special setup needed on the partner side — this happens entirely within MDI's clinical workflow.

## Recorded-intro-video states

A smaller set of states instead accept a short pre-recorded intro video from the patient in place of a live session. For these states:

* The video is typically expected to be **under 10 seconds**.
* It must include the patient stating:
  1. Their full name
  2. Their date of birth
  3. Their state
  4. The condition being treated

To attach the video to a Patient:

1. Upload it through the Files API:

   ```
   POST https://api.mdintegrations.com/v1/partner/files
   Content-Type: multipart/form-data
   ```

   The response returns a `file_id`.
2. Pass that `file_id` as `intro_video_id` when creating or updating the Patient:

   ```json
   {
     "intro_video_id": "{{ fileId }}"
   }
   ```

## Finding which states require this

Don't hardcode a state list — requirements can change over time as state laws shift. Instead, call the **Get States** endpoint and check the `is_av_flow` flag on each state:

```
GET https://api.mdintegrations.com/v1/partner/states
```

A state with `is_av_flow: true` is a recorded-intro-video state. Use this to decide, at intake time, whether your flow needs to collect a video for that patient.

{% hint style="warning" %}
Query this endpoint rather than caching the result indefinitely — treat it as the source of truth each time you need to branch intake logic on state requirements.
{% endhint %}

## Reducing friction

If a state on your patient's flow requires a video, consider embedding an inline webcam plugin directly on your own intake page so the patient can record it without leaving your product. This avoids sending them to a separate app or asking them to upload a file from their device, which is where most drop-off happens.

<details>

<summary>If no video is uploaded at Patient creation</summary>

You aren't required to have the video in hand before creating the Patient record. If `intro_video_id` is omitted and the patient's state requires one, MDI can configure your account to automatically email the patient a white-label experience where they can record and upload their own video afterward. Ask your MDI account contact to enable this fallback if you'd rather not block Patient creation on video capture.

</details>


---

# 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/troubleshooting/technical-concepts/state-av-sync-requirements.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.