Get StartedUse CasesMedically Tailored Meals

Overview

Medically tailored meals (MTM) is a Truemed flow for merchants who sell prepared meals and want their customers to be able to pay with HSA/FSA funds. It is built for food catalogs, where eligibility depends on a customer’s dietary needs rather than on a single product being medically necessary on its own.

The customer qualifies first, before any meals are selected. They complete a Truemed health survey. An independent licensed practitioner then reviews their case for a Letter of Medical Necessity (LMN), the document that establishes that an expense may be paid for with HSA/FSA funds. Based on the survey answers, Truemed returns to you the items from your own catalog that fit that customer’s dietary needs and may be purchased with HSA/FSA funds if the practitioner determines medical necessity.

This mirrors the offline pattern of a dietitian assessing someone’s needs and matching meals to them. Truemed never tells the customer what to eat. Truemed tells you which of your existing meals apply to that customer, and you decide how to present them.

How it works

At a high level, the flow runs in four movements:

  1. Signup. You create a payment token request, and you embed the Truemed-hosted health survey and payment form in your page.
  2. Qualification. The customer completes the health survey and enters two cards: an HSA/FSA card and a regular credit or debit card. An independent licensed practitioner reviews the case for an LMN.
  3. Decision. Truemed mints a payment token that vaults the eligibility decision and both payment methods together, and tells you about it on the payment_token.updated webhook.
  4. Ordering. You read eligibility to learn which items this customer may put on their HSA/FSA card, and you charge each order against the token. Truemed splits every charge across the two cards.

How this differs from the standard Truemed flow. In the standard flow the customer picks products first and qualifies during or after checkout. In MTM, qualification leads and the catalog follows: the survey result shapes what the customer is shown, so eligibility is known before the first basket is assembled.

Two properties of the flow to hold on to

Customers come back regularly. Most MTM merchants sell subscriptions, and subscribers return on a rhythm, typically once a week, to pick the meals for their next box. Each of those visits is an ordinary order charged against a token that already exists, with no new health survey and no new card entry. Subscriptions are the common case rather than a requirement: the token vaults the eligibility decision and the payment methods together, and whether you use it for recurring charges or for one-off purchases is your decision.

Food is only partially eligible for HSA/FSA spend. Even for a meal the LMN covers, only a portion of the price may go on the benefits card. Every customer therefore provides two cards, and every charge splits across both: the HSA/FSA card takes the eligible portion, and the regular credit or debit card takes the remainder. The second card is part of the normal path for every order. The ineligible portion is a fixed dollar amount per meal, the price of a comparable grocery meal, so every order is a split; see Comparable meals.

One word to pin down before we go further: items. Throughout this guide and in every API payload, an item is an individual meal, one dish a customer can add to a box, identified by its SKU in your catalog. It is not a subscription plan or a meal-plan tier. If “SKU” means the plan-level product in your systems, read items and order_items as “the individual meals in this order”. The survey outcome always comes back as a list of these items.

Where to go next

  • The first order: the one order that waits on the practitioner’s decision, and how you hold it.
  • Subsequent orders: the steady state, the two-card split, expiring cards, and requalification.
  • API calls: every call this integration makes, the signup payloads, and what the eligibility read answers with.
  • Embedding the flow: the iframe and the message your page listens for.

Getting your menu classified

Everything in this guide assumes we already know which of your meals may be HSA/FSA-eligible. Establishing that, including the nutrition and ingredient data we need, the format, the cadence for menu changes, and turnaround on newly added meals, is a separate workstream from the API integration. It is handled operationally rather than through the API you build against. Your Truemed contact runs it alongside the integration, so your engineering team is never waiting on it. Nothing in this guide is blocked on it.