> 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/patient-portal.md).

# Patient Portal

Configure and embed the hosted portal for authenticated patients.

The Patient Portal is the post-login area of the white-label Patient App — everything a patient sees once they've authenticated. It's entirely config-driven from the Partner Portal, which means your team can add, remove, or rearrange pages and components without writing code or waiting on an MDI release.

<figure><img src="https://1351412531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FYCoNzBEmH2t5SFktn01I%2Fuploads%2FQCwVsHDJzXKeRX5UG1Si%2FScreenshot%202026-09-23%20at%2017.39.43.png?alt=media&amp;token=2ad460d6-fba6-48e1-81a2-a8b0d55acd1a" alt=""><figcaption></figcaption></figure>

## What it surfaces

Out of the box, the Portal gives patients a self-service view into their care:

* **Encounters** — visit history, the assigned clinician, and pharmacy/treatment details for each case
* **Orders** — fulfillment status tied to an Encounter
* **Subscriptions** — recurring treatment plans and renewal state
* **Messaging** — a direct channel to the assigned clinician or your support team
* **Health trackers** — weight, height, blood pressure, symptoms, and other patient-reported metrics over time
* **FAQs** — configurable help content
* **File uploads** — lab results and other documents the patient submits or receives
* **Account settings** — profile info and notification preferences

Since the layout is config-driven, you decide which of these a given brand actually needs rather than shipping all of them by default. A weight-loss offering, for instance, might lead with health trackers and subscriptions, while a one-off consult flow might only need Encounters and messaging.

## Standalone component embeds

You don't have to expose the full Portal to get value from it. Any individual page — and in some cases a single component — can be embedded on its own via a dedicated deep link, which makes this the common path when a partner already has their own app or website and just wants to drop in one piece of MDI's patient experience rather than iframe the whole Portal.

Typical use cases include:

* Embedding just the **messaging** widget inside an existing partner app, so patients never have to leave it to reach their clinician
* Embedding just **order tracking** on a partner's existing account/order-history page
* Linking directly to the **health tracker** from a wellness dashboard

## Recipe: embed only the messaging component

Instead of linking to the full Portal URL, use the component-specific embed deep link for messaging. This renders just the message thread with the patient's assigned clinician or support team — no navigation chrome, no other Portal pages — so it drops cleanly into an existing partner surface such as a modal or a tab in your own app.

The same pattern applies to any other single page or component you want to surface standalone: just swap in that component's deep link in place of the full Portal URL.

{% hint style="info" %}
**Note:** Standalone embeds still require the patient to be authenticated. Deep-link URLs don't bypass login — they only change what renders after it.
{% endhint %}


---

# 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/patient-portal.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.
