Platforms and marketplaces: whose website is being certified

Platform businesses arrive at certification with an assumption baked into the product: that they provide software and somebody else provides care. It is a reasonable commercial position and it is not how the question is decided.

The question is decided by the website a patient uses, what happens on it, and whose name is on the transaction.

The determining question

Where does the patient hand over money, and to whom?

If the patient completes intake and pays on your domain, under your brand, that is your website and your commercial relationship, whatever the contracts say about who provides care. The certified thing is a website, and this is the website.

If the patient transacts on the clinic's own domain, using software you supply, the clinic's site is the one in question and yours is a business-to-business product.

The uncomfortable middle is the white label: a domain owned by the clinic, running your product, with your infrastructure, your intake and your fulfilment relationships behind it. That one has to be answered site by site, and somebody has to own the answer.

The four architectures, briefly

Marketplace. Patients browse providers or products on your domain and transact there. You are the merchant the patient sees, and your site is the one carrying the claims.

Aggregator or directory. You list providers and send traffic away without taking payment. Your exposure is what your listings claim, which is a marketing question rather than a certification one for the transaction, though the counterparties who screen on the credential will still ask.

White label. Each customer has a domain, and each domain is a separate certification question. Twenty clinics is potentially twenty applications, and whether they are yours or theirs is a contract term that most white-label agreements do not address.

Enablement. You supply software, and the clinic runs everything patient facing. Cleanest position, and the one platforms claim most often and occupy least often.

What platforms consistently underestimate

The intake is yours. If the assessment logic, the questions and the decline rules are your product, then the clinical screening a reviewer examines is something you built. That is a strength if it is documented and a problem if nobody can explain it, which is the argument asynchronous intake makes for instrumenting it.

The pharmacy relationship is often yours too. Where the platform arranges fulfilment, the dispensing entity, its registration and its state coverage are part of your model rather than each clinic's.

The claims are copied. White-label customers use the templates you supply. One badly worded product description in a template is that sentence live on twenty domains, and every one of them is discoverable.

Your customers inherit your compliance. A clinic on your platform is buying your intake, your fulfilment and your copy. If those are sound, you are selling a genuine advantage. If they are not, you are distributing a defect.

The contract questions nobody writes down

Settle these before the first customer, because retrofitting them across twenty signed agreements is a different job.

• Which party holds certification for the customer's domain, and who pays.
• Who owns the claims on the customer's site, and whether template copy may be edited.
• What happens when a customer edits it into something non-compliant.
• Who answers a request for information about the shared clinical model.
• What happens to patients if the relationship ends mid-treatment.
• Whether the platform may suspend a customer for a compliance breach, and on what notice.

That last one is the clause platforms wish they had. Without it, a single customer's landing page can put the whole network's reputation with acquirers and ad platforms in play.

The domain sprawl a platform creates

Platforms generate domains faster than any other business model in this industry, and most of them appear without a decision.

A subdomain per customer for their patient portal. A shortlink domain for messaging. A demo environment that is publicly reachable and indexed. A marketing site, a documentation site, a status page, and a legacy domain from the product's first name. Then each customer's own domain on top.

Not all of those need certifying and every one of them needs to be known about, because an undisclosed reachable property is the cheapest kind of finding to avoid and one of the more damaging to have found. Pull the list from the DNS provider rather than from the registrar alone, since a platform's sprawl is usually in subdomains rather than in registrations.

Then apply the same three buckets everything else in this business uses: certify, redirect, retire. A demo environment that anybody can reach and that takes intake is a live telehealth website whatever the internal name for it is.

The advantage available to platforms

There is a genuinely good version of this. A platform that certifies its own marketplace domain properly, documents the shared clinical model once, maintains the pharmacy evidence centrally and supplies customers with a compliant template and a claims allowlist is selling something valuable, and it is the single strongest differentiator available in a crowded software category.

It also makes each customer's own application dramatically cheaper, because most of the shared evidence already exists in a form that can be handed over.

What to prepare either way

One document describing the shared model: the intake, the screening logic, the prescriber relationships, the dispensing arrangement, the state coverage, and which parts a customer can change. One certified domain if you take payment. One template audited against the claims rules. And a clear internal answer, per customer, to whose website is whose.

Platforms that cannot answer that last question are usually the ones who find out during a customer's review, which is the worst moment to be having the conversation.