> 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/key-concepts/patient-notifications.md).

# Patient Notifications

MDI sends 11 distinct patient-facing notification types by default — messages, missing-document requests, ID verification prompts, intake reminders, and more. If you'd rather own that communication yourself, you can disable specific MDI notifications in the Partner Portal and replace them with your own emails, driven by MDI's webhooks instead.

{% hint style="info" %}
Prerequisites: admin access to the Partner Portal Admin Panel, a webhook endpoint on your own server, and access to your own email service provider (ESP).
{% endhint %}

{% hint style="warning" %}
You should only disable a notification if you have a corresponding custom email template and delivery logic ready to replace it. Disabling a setting without a replacement in place doesn't just remove MDI's branding — it means the patient stops receiving that communication entirely.
{% endhint %}

## Step 1: Audit the notification catalog and disable in the Admin Panel

MDI's white-label notification system covers 11 distinct notification types. Most are white-labeled (shown under your own brand) and most can be toggled off from the Partner Portal (Integration → App Setup → Notifications) if you'd rather send your own instead. A few, however, are permanent and always sent under MDI's own name — see the note below before you start disabling anything.

<table><thead><tr><th>Notification Type</th><th width="286.5703125">What Triggers It</th><th>Can Be Disabled?</th></tr></thead><tbody><tr><td>New Message</td><td>A clinician or support user sends a message to the patient from the Clinicians App</td><td>Yes</td></tr><tr><td>Driver's License Upload</td><td>An Encounter is created with no driver's license on the patient's profile; can also be triggered manually from the Clinicians App</td><td>Partial — skipped automatically if the partner's "DL on voucher" setting is enabled</td></tr><tr><td>AV Flow (Intro Video)</td><td>An Encounter is created for a US state that requires the audio/video flow (check the <code>is_av_flow</code> flag via the Get States endpoint) and no intro video is on file; can also be triggered manually from the Clinicians App</td><td>Partial — avoidable by attaching the intro video to the patient's profile before creating the Encounter</td></tr><tr><td>Intake Form Reminder</td><td>Fixed cadence — 4 hours, 24 hours, and 48 hours after the voucher/intake was started — for patients who haven't completed it</td><td>Yes</td></tr><tr><td>Email Update</td><td>The email address on a patient's profile is updated, manually or via the API</td><td>No</td></tr><tr><td>Data Access Request</td><td>A patient requests a copy of their data via the Data Requests section of MDI's website</td><td>No</td></tr><tr><td>Data Deletion Request</td><td>A patient requests their profile be deleted via the Data Requests section of MDI's website</td><td>No</td></tr><tr><td>2FA (Two-Factor Authentication)</td><td>A patient needs to be authenticated (Patient App access, replying from an expired link, requesting data access/deletion, etc.)</td><td>No</td></tr><tr><td>General Files Upload</td><td>An Encounter is created and a required file is missing from the patient's profile (full-body photo, lab order results, medication photo, etc.); can also be triggered manually from the Clinicians App</td><td>Yes</td></tr><tr><td>Body Metrics Update Request</td><td>A patient's body metrics (allergies, current medications, weight, height, etc.) need to be added or updated; typically triggered manually from the Clinicians App</td><td>Yes</td></tr><tr><td>Preferred Pharmacy Request</td><td>A patient needs to select their preferred local pharmacy; typically triggered manually from the Clinicians App</td><td>Yes</td></tr></tbody></table>

{% hint style="warning" %}
Four notification types — **Email Update**, **Data Access Request**, **Data Deletion Request**, and **2FA** — can't be disabled and never carry your brand, regardless of your theme or notification settings. These are compliance- and security-critical by design.
{% endhint %}

## Step 2: Subscribe to the matching webhook

Once you've decided which notifications to disable, the next step is making sure you don't lose visibility into the events behind them. Every disabled setting has a corresponding webhook event you should listen for instead, so that your own system picks up exactly where MDI's notification would have fired. See Webhook Setup & Signature Verification to configure your endpoint, and Webhook Event Catalog for full payload detail on each event below.

| Disabled setting         | Webhook event to listen for instead                                | What to do with it                                                         |
| ------------------------ | ------------------------------------------------------------------ | -------------------------------------------------------------------------- |
| New messages             | `message_created`                                                  | Extract the message ID and trigger your own custom notification            |
| Workflow requests        | `exam_requested`, `intro_video_requested`, `file_upload_requested` | Alert the patient to missing intake info or clinical tasks                 |
| Missing driver's license | `drivers_license_requested`                                        | Trigger your own branded verification-request email                        |
| Incomplete intake        | `voucher_created`                                                  | Use the event's timestamp to drive your own 4/24/48-hour follow-up cadence |
| Pending workflows        | `case_waiting`                                                     | Monitor for stalled cases that need patient action                         |

{% hint style="warning" %}
Your server should respond with a `200 OK` status as soon as it receives the payload. Acknowledge first, then process asynchronously — don't make MDI's delivery wait on your notification logic before you return `200`. See Retry Policy & Idempotency for what happens if you don't.
{% endhint %}

If you'd rather not stand up a webhook receiver at all, an Automation triggered off the same events can drive this logic instead — see the general notification scheduler recipe there for the equivalent no-code approach.

## Step 3: Worked example — replacing the incomplete-intake reminder

With the concepts in place, it helps to walk through a complete example end to end. Here's the full recipe for replacing MDI's intake-abandonment reminder (the "Remind patient of incomplete intake form" setting) with your own branded email.

{% stepper %}
{% step %}

### Filter the event

From the `voucher_created` webhook payload, extract `patient_id`, `voucher_id`, and `timestamp`. Anchor your reminder schedule off that timestamp — not off whenever your server happens to process the webhook — so your timing stays accurate even if delivery is delayed.
{% endstep %}

{% step %}

### Resolve the patient's identity

Next, call the Get Patient endpoint to retrieve their full profile, including email and first name, so you can personalize your reminder:

{% code title="Get Patient" %}

```
GET https://api.mdintegrations.com/v1/partner/patients/:patient_id
```

{% endcode %}
{% endstep %}

{% step %}

### Check whether they've already engaged

Before sending anything, query the Get Patient Events endpoint for that patient, looking for a `voucher_used` or `case_created` event. If either is found, the patient already completed intake, so cancel your planned reminder rather than sending a redundant one.
{% endstep %}

{% step %}

### Generate a pre-authenticated deep link

Now call the Get Messaging App URL endpoint (or the equivalent embed endpoint for the flow you're reminding them about):

{% code title="Get Messaging App URL" %}

```
GET https://api.mdintegrations.com/v1/partner/patients/:patient_id/auth?fullscreen=true&full=true
```

{% endcode %}

| Parameter         | Description                                                        |
| ----------------- | ------------------------------------------------------------------ |
| `patient_id`      | associates the link with the correct patient.                      |
| `fullscreen=true` | removes MDI branding and borders, for a seamless white-label feel. |
| `full=true`       | grants complete application access rather than a single component. |

The underlying `/auth` endpoint generates a temporary, secure token, so the patient skips the login/OTP screen entirely when they click through.
{% endstep %}

{% step %}

### Send your own branded reminder

Finally, dispatch the email via your own ESP, with the secure deep-link URL as the primary call-to-action button.
{% endstep %}
{% endstepper %}

The result: the patient gets a fully-branded reminder from your own system, and clicking it drops them, already authenticated, straight into MDI's flow — in a fullscreen view that looks native to your own product.


---

# 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/key-concepts/patient-notifications.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.