> 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/tags-and-wildcards.md).

# Tags & Wildcards

Tags and Wildcards are two small but frequently used features for organizing data and personalizing communication at scale. They aren't functionally related to one another, but both show up constantly across the Partner Portal, so it's worth covering them together here.

## Tags

**Tags** are labels that partners or staff apply to Patients or Encounters for organization and filtering. Use them to group records by whatever dimension matters to your operation — treatment type, priority, campaign source, internal review status, or anything else you need to slice your patient or encounter list by.

Common examples:

* Tagging Encounters by treatment type (e.g., `weight-loss`, `dermatology`)
* Tagging Encounters by priority (e.g., `needs-review`, `urgent`)
* Tagging Patients by acquisition source or cohort

Once applied, Tags aren't just cosmetic labels — you can use them to filter lists in the Partner Portal, and you can reference them in Automation branching logic, for example routing an Automation differently depending on whether an Encounter carries a particular Tag.

## Wildcards

**Wildcards** are merge-variable placeholders you drop into message templates and clinical note templates. MDI expands them into the real value automatically when the template is sent or used, so you write the template once and every patient sees their own personalized version.

Common Wildcards include things like the patient's full name, first name, and gender, referenced inside a template using MDI's placeholder syntax.

### Why this matters

Without Wildcards, sending a personalized message to a hundred patients means writing — or manually editing — a hundred separate messages. With them, you write the template once and reuse it indefinitely, letting MDI handle the substitution for every patient it goes out to.

## Recipe: a reusable, personalized message template

{% stepper %}
{% step %}

### Open the editor

Open the message template editor in the Partner Portal.
{% endstep %}

{% step %}

### Draft the message

Draft the message using Wildcards where personalization is needed, e.g.:

{% code title="Message template" %}

```
Hi [patient_first_name], your refill is ready to schedule.
```

{% endcode %}
{% endstep %}

{% step %}

### Save the template

Save the template.
{% endstep %}

{% step %}

### Reuse the template

Use the same template across every patient it applies to — an Automation Step, a manual message, or a bulk send. MDI substitutes each patient's actual first name at send time.
{% endstep %}
{% endstepper %}

The same approach carries over to clinical note templates: build the note structure once with Wildcards standing in for patient-specific details, and reuse it across Encounters instead of retyping the same boilerplate every time.

{% hint style="info" %}
Wildcards only resolve inside templates that support them (message templates and clinical note templates). They aren't a general find-and-replace across the Portal.
{% 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/tags-and-wildcards.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.