Why consultation-to-treatment conversion is an architecture problem

The state that has no home

In a split stack the appointment and the assessment are held by different products. The practice or booking platform owns the appointment record, the payment and the schedule. A separate consultation record owns the assessment, the images and the documented treatment plan. Both halves are internally complete. What neither product holds is the compound state that matters commercially — plan documented, treatment not booked — because computing it means reading across a boundary that carries no shared patient identifier unless one was deliberately built. That is the mechanic the aesthetic practices revenue architecture page describes structurally. And a state is not an impression of how a visit went: it is a row — a person, a modality, a plan reference, the date the plan was documented, an owner, an age, and a reason code for why it stopped moving. Where that row does not exist there is nothing to sort, nothing to escalate, nothing to close and nothing for an automation to fire against. The absence is silent, which is why it survives review — a report cannot show the absence of the object it would have counted.

Which half of the record holds what

Read down that table and the failure appears as a shape rather than as a fault. Every row is internally consistent and every system is doing its job. The break sits between the consultation row and the treatment row: the only evidence that a plan was documented lives in a system the scheduler never queries, and the only evidence that the plan was acted on is the presence of a later appointment. Inside the booking platform, therefore, the absence of a later appointment is indistinguishable from a person who never had a plan at all.

Why this cannot be solved by adding an automation

The reflex is to subscribe an automation to the consultation outcome. In published vendor documentation that event does not necessarily exist. One booking platform’s documented webhook surface covers appointment booked, updated or canceled; sale completed; and form submitted — and enabling webhooks at all is documented as a support request rather than a self-serve setting ^[SRC-25]. Consultation outcome, treatment-plan status, package depletion and membership utilisation are not on that surface. An automation designed to fire on them has nothing to subscribe to.

• State changes a follow-up design needs: a plan was documented and no treatment was booked; a plan aged past its own review window; a package balance fell to its last redemption; a membership passed a billing cycle with no visit.
• State changes a documented event surface may publish: an appointment was booked, updated or canceled; a sale completed; a form was submitted ^[SRC-25].
• What the difference forces: scheduled polling against a modified-since filter, a person maintaining a list by hand, a plan-tier upgrade the client has to fund, or a vendor support request that must be actioned before anything can be built.

Those options are not equivalent. Polling collapses state changes that occur between polls, so a plan documented and superseded inside the interval is invisible to the poll that follows it. A hand-maintained list inherits the availability of the person maintaining it. A tier upgrade moves the constraint into a commercial negotiation. A support-gated enablement introduces a dependency on a third party’s queue. Choosing between them is an integration and orchestration decision that belongs before the follow-up design is agreed, not after it.

What follow-up is permitted to do once the state exists

Creating the object does not by itself create permission to contact the person. Automated telemarketing calls and texts require prior express written consent under the FCC delivery restrictions at 47 CFR 64.1200; revocation may be expressed by any reasonable method clearly expressing a desire not to receive further calls or text messages, and must be honored within a reasonable time not to exceed ten business days ^[SRC-14]. Separately, where an entity is a covered entity, 45 CFR 164.508 states it ‘must obtain an authorization’ for uses or disclosures of protected health information for marketing, with exceptions for a face-to-face communication and a promotional gift of nominal value; where third-party financial remuneration is involved, ‘the authorization must state’ that it is ^[SRC-13].

Whether a particular entity is a covered entity is a determination about that entity, made on its own facts with qualified counsel. It is not a property of a category of business, and this page does not make it. What it does mean for architecture is that the permission model belongs in the design of the queue rather than bolted onto the messaging step: the object that holds the state should also hold the consent state, the channel eligibility and the revocation record, because a follow-up system that cannot answer may we contact this person, on this channel, today is not finished.

The reconciliation that would confirm the gap

1. Export every completed appointment of a consultation type from the practice or booking platform for a trailing window, with patient identity, provider, date and appointment type.
2. Export every consultation record carrying a documented treatment plan for the same window, with patient identity, plan date and modality.
3. Join the two on whatever identity key exists, and record how the join was performed — an automatic key, a name-and-date-of-birth match, or a person reading two screens. The method is itself a finding.
4. For each joined row, look forward for a treatment appointment of the corresponding modality. Rows with no forward appointment are the population in question.
5. For that population, check whether any task, queue entry, message or automation log exists at all. Where none does, the state was never computed anywhere — which is the architectural claim, and it is verifiable without knowing anyone’s intent.

What this does not establish

The reconciliation establishes that a state was not computed. It does not establish that the plans in question were recoverable, and it assigns no value to them. Deferral, price, scheduling, provider availability, a decision made after leaving, and a booking taken under a second duplicate record all resolve to the same missing row. Nothing here is a statement about any specific practice, no rate or financial impact is asserted, and no clinical or regulatory judgement is offered. A Revenue Leak Scan reviews public-visible signals only — it cannot read the practice’s own records, so it can frame this question but not settle it. The reconciliation above is run inside the practice’s systems, by the practice.