Your Meal-Plan Generator Climbs a Licensing Ladder Every Time a User Mentions a Lab Result

The activity

Non-individualised facts about food, nutrients and dietary patterns, delivered the same way to everyone who asks.

The product surface that does it

A food database, a macro reference, an article library, a recipe search that does not know who is searching.

Does the "it's just software" argument hold?

Practice acts regulate the application of nutrition principles to a particular person. Information published to the world has no particular person in it, and states that regulate dietetics generally carve out the dissemination of nutrition information explicitly.

The activity

Advice tailored to an individual's stated goals and preferences, without assessment of a clinical condition — calorie targets from height, weight and activity level.

The product surface that does it

The onboarding quiz that produces a daily calorie and macro target, and a weekly plan built from it.

Does the "it's just software" argument hold?

This is where state law diverges most. Some states restrict only the title 'dietitian' or 'nutritionist' and leave the activity open. Others restrict the practice itself, defining it broadly enough that any individualised dietary recommendation is inside the perimeter regardless of what you call yourself.

The activity

Evaluating an individual's nutritional status by gathering and interpreting data — intake history, anthropometrics, biochemical values, medical history.

The product surface that does it

The integration that pulls lab results, the symptom questionnaire that asks about digestion and fatigue, the connected CGM feed.

Does the "it's just software" argument hold?

It does not. Assessment is the first named component of the practice of dietetics in most statutory definitions. A product that ingests a lab value and characterises the user's status from it has performed the assessment step, and the fact that a model rather than a person performed it is not an exception written into any of these statutes.

The activity

Naming a nutrition-related problem and prescribing a corrective dietary regimen, including nutrient levels, supplementation and timing.

The product surface that does it

The plan that says the user is likely low in iron and prescribes a schedule to correct it.

Does the "it's just software" argument hold?

It does not. 'Prescribing' is a listed act, and the framing that the app merely 'suggests' does not survive a reading of the output, which reads as an instruction with quantities and a duration.

The activity

Nutrition intervention for the management of a diagnosed disease or condition — diabetes, kidney disease, celiac, eating disorders, oncology, pregnancy complications.

The product surface that does it

The moment the user mentions a diagnosis and the plan changes in response to it.

Does the "it's just software" argument hold?

It does not, and this rung carries the additional weight that harm is foreseeable and specific. A potassium recommendation appropriate for a healthy adult and one appropriate for someone with reduced kidney function differ by an amount that matters clinically.

GATE 1Is it a disease claim?

The test: Does the product state or imply that it diagnoses, treats, cures, mitigates or prevents a disease? Implication counts — before-and-after imagery, condition-named landing pages, testimonials describing a condition resolving, and metadata targeting a condition all carry meaning.

If you fail it: A disease claim moves the product into a regulated category regardless of its software packaging, and the compliance burden that follows is not one a consumer wellness app is built to carry.

GATE 2Is the health claim substantiated before it ships?

The test: Advertising claims about health outcomes require competent and reliable scientific evidence in hand at the time the claim is made. The standard is prior substantiation — being right later does not cure it.

If you fail it: Unsubstantiated health claims are the FTC's most reliably enforced consumer-protection theory, and 'the model generated the copy' identifies the mechanism rather than a defence.

GATE 3Are results typical, and does the page say so honestly?

The test: Outcome figures and testimonials must reflect what users generally achieve. A prominent disclaimer does not rehabilitate an atypical headline result.

If you fail it: This is the specific failure mode of AI-generated marketing pages, which produce confident outcome numbers because the training distribution is full of them.

GATE 4Does a generated answer become a claim?

The test: A model's in-product statement to a user that the plan will lower their cholesterol is a representation made by your product, made individually, at scale, unreviewed.

If you fail it: The advertising claims you review are the ones on the marketing site. The volume of claims your product makes is in the chat transcript, and nobody is reading it.

Does a dietetics practice act actually apply to software?

The statutes are written in terms of acts, not actors, and that is what makes the answer uncomfortable. A typical definition covers assessing nutritional status, developing a nutrition diagnosis, and planning and prescribing nutrition intervention for individuals — none of which is limited to acts performed by a human being. The counter-argument, which vendors reach for, is that the software is a tool used by the consumer rather than a person practising a profession. That argument works best when the product genuinely is a calculator: the user supplies inputs, a documented formula runs, the output is the formula's result. It works worst when the product does the thing a professional does — gathers a history, interprets clinical values, forms a conclusion about the person, and issues an individualised regimen in the register of an instruction. Regulators in adjacent professions have already resolved this pattern the same way, treating the question as what was performed rather than who performed it. Assume the perimeter reaches the conduct and design the product so the conduct stays outside it.

Is a licensed dietitian on staff enough?

It is necessary well before it is sufficient, and the gap between the two is where the exposure lives. Licences are state-specific, so a single credentialled employee covers the states where they hold a licence, not your user base. Supervision has to be real: statutes that permit supervised practice generally require the licensee to have knowledge of and responsibility for the individual case, which a monthly sample review of generated plans does not satisfy. And there is a documentation problem — if a licensee is responsible for an intervention, there should be a record of the licensee's involvement in that specific person's plan, which most automated products cannot produce because no such involvement occurred. The workable version of this control is narrow: a licensee reviews and approves the rules, the templates, the escalation gates and the restricted-population handling, and every individualised clinical output is routed to a licensee in the user's state before it reaches the user. If that routing is too expensive to operate, the product is not ready to produce individualised clinical outputs.

Do our disclaimers protect us?

They help with one problem and not the one people think. A disclaimer stating the product does not provide medical advice can support the argument that no professional relationship was formed and can matter in a negligence claim about reliance. It does not answer a licensing charge, because the question there is what the product did, and a footer does not change the content of an output that assessed a person and prescribed a regimen. Disclaimers also degrade with contradiction: a footer saying 'not medical advice' underneath an interface that ingests lab results, names a likely deficiency and issues a corrective protocol is evidence of awareness rather than a defence, and the mismatch between the two is exactly what a regulator quotes. Treat the disclaimer as one control among several and make sure the others exist — enforced scope gates, restricted-population handling, refusal paths that actually refuse, and marketing copy that describes what the product does rather than what a clinician does.

Which states are the actual problem?

The distinction that matters is not geography but statutory type, and it splits three ways. Title-protection states restrict who may call themselves a dietitian or nutritionist while leaving the underlying activity open — these are the permissive case, and the compliance work is mostly about naming and credential display. Practice-act states restrict the acts themselves, and their definitions of assessment and nutrition intervention are broad enough to cover an individualised plan whatever the provider is called. A third group sits in between, restricting practice but writing exemptions for general information, for non-clinical weight-management counselling, or for specific credential-holders. Because a national app is available everywhere, the operative rule is the most restrictive one in your user base unless you geo-gate features by state, which is possible but has to be built. The practical starting point is to classify each product surface by rung on the spectrum above, then determine which states restrict that rung, rather than trying to summarise fifty statutes at once.

What about integrations — CGMs, lab results, EHR data?

Every clinical data integration moves the product up the spectrum, and that is the point of the integration, so the two are hard to separate. Reading a continuous glucose monitor and adjusting a meal plan in response is nutrition intervention informed by biochemical data, which is the textbook description of assessment plus intervention. Alongside the scope question, these integrations bring their own regimes: clinical data received from a covered entity may carry contractual and regulatory obligations, some state privacy laws treat health inferences as sensitive data requiring separate consent, and an inference that a user has a condition is itself health data even if the user never said so. The design consequence is that clinical inputs and clinical outputs should be gated together. If the product reads a lab value, it should either route the resulting recommendation through a licensee or restrict its output to information rather than instruction — reporting what a value means in general terms without prescribing the individual's corrective regimen.

What is the realistic enforcement picture?

Three channels, in ascending order of likelihood. State licensing boards can issue cease-and-desist orders for unlicensed practice, and they act on complaints, which most often come from credentialled professionals who encounter the product rather than from users. Consumer-protection enforcement targets the advertising claims, and this is the channel most likely to reach a growing app because health claims are visible, cheap to evaluate and easy to prove unsubstantiated. Private litigation follows an incident, and here the licensing question returns as a negligence-per-se argument — a plaintiff alleging harm from a recommendation will point to the unlicensed practice as the breach, which converts a regulatory issue into a damages case. There is also a quiet fourth channel that hits earlier than any of these: platform and payment review. App-store health-claim policies and payment-processor restrictions on health products are enforced by private parties with no due process and no notice period, and a takedown at that layer arrives before any regulator does.