Two audiences with two risk profiles: the patient and the organisation buying

Any message suggesting somebody is in danger has exactly one correct response, and it is signposting: the emergency number and the crisis line, in the first reply, ahead of everything else. Not a contact form, not a promise of a call back, not a suggestion to book something.

Build this into the refusal wording rather than leaving it to composition, and set the caution level so an ambiguous message gets the serious reading. A false positive costs somebody a slightly odd reply. A false negative costs something else entirely.

Whether somebody is a user, whether they have an appointment, what is in their record, whether a result has come back. Health data is a special category in most data protection regimes, and the mere fact that a named person uses a health service is itself health information.

The assistant has no record access and must never behave as though a confirmation would be harmless. Even a denial can disclose, so the answer is that it does not discuss individuals at all, uniformly, including with somebody who says they are the person concerned.

Is this suitable for my condition, can I use it alongside my medication, does this mean my reading is bad, should I stop using it before an operation. These arrive constantly on a health product because the product is about health, and they are clinical questions whatever the framing.

The distinction to hold is between describing what the product does, which is safe, and applying it to a person, which is not. The refusal should name a real route: their own clinician, the service they came through, or the crisis line where the message warrants it.

This is the hardest one to refuse, because the requester is legitimate, professional and probably entitled to the information through a proper channel. It is still not something a public chat widget can verify or supply.

Handle it as a routing question rather than a rebuff: name the authenticated channel or support route that handles patient specific queries, and take the details for a call back. The assistant's inability to know who it is speaking to is the whole reason, and it is worth saying so plainly to a professional who will understand it immediately.

In most major markets, software intended to diagnose, prevent, monitor, predict or treat can fall within medical device regulation, and the trigger is the intended purpose the manufacturer states. That makes the wording of your own explainers more than marketing: it is part of what determines the regime you sit in.

This has a direct consequence for indexing. Every page the assistant reads is a page whose claims it will repeat and rephrase, so material that overstates what the product does becomes an assistant that overstates it too, in writing, to anybody who asks. Index the wording your regulatory and clinical people signed off, and nothing looser.

The same corpus serves both, but the duties differ. To a member of the public the assistant is cautious, non clinical and quick to signpost. To a professional buyer it can be detailed, technical and precise about data handling, retention and interoperability.

It cannot reliably tell which of the two it is talking to, so the safe design is to hold the patient facing constraints at all times and let the governance detail be available to whoever asks for it. Detailed answers about data flows harm nobody. Casual answers about health do.

Requests to export or delete personal data carry response deadlines in most data protection regimes, and health data attracts the most scrutiny when they are handled badly. Index the process, let the assistant explain it exactly, and route the request to somebody who will action it inside the deadline.

Accessibility is the duty people forget. Public facing health services face accessibility standards in many jurisdictions, and an assistant is a public facing service. Make sure your access, alternative format and language support information is indexed rather than treated as an edge case.