Post-treatment care by message: where the clinical line sits

Automating post-treatment communication in a clinical setting raises a question that does not arise when you are sending order updates: at what point does a message stop being information and start being advice.

The line matters because the consequences differ. Delivering instructions a clinician wrote is administration. Responding to a patient describing a symptom is clinical judgement, and it belongs with somebody qualified and accountable whatever channel the question arrived on.

What we'll cover

• Information, instruction, advice
• Who owns the content
• The question that must never be answered automatically
• Designing the escalation
• Building it with CodeWords
• Consent, and what patients agreed to
• What goes in the record
• Detail in the message itself
• Out of hours, which is when it matters
• Making it survive
• Limits worth knowing about
• What to settle first
• Frequently asked questions

Information, instruction, advice

Three categories, and only the first two belong in an automation.

Information. Fixed facts. When the appointment was, what was done, when to return, how to contact the clinic. No judgement involved.

Instruction. What a clinician has already decided the patient should do, written in advance, applying to everybody having that treatment. Keep it dry for a day. Take the prescribed course as directed. Avoid strenuous activity until Thursday.

Advice. A response to this patient's particular situation. Whether their swelling is normal, whether they should stop a medication, whether what they are describing needs attention today.

An automation delivers the first two and routes the third. That boundary is easy to state and needs writing down, because the pressure to blur it comes from a good place: somebody is worried, an answer would reassure them, and the reassurance is usually right. Usually is the problem.

Who owns the content

Every message in the sequence is clinical content and needs a clinician's name against it.

Approved by somebody, on a date. Not written by whoever built the automation and approved by nobody.

Version controlled. When guidance changes, you need to know which patients received which version and when it changed.

Reviewed on a schedule. Practice changes, products change, guidance changes. A sequence running unreviewed for three years is sending last year's instructions with your name on them.

Owned after the person who wrote it leaves. Content whose only approver has moved on is content nobody is accountable for.

This is ordinary governance applied to a channel where it often gets skipped because the messages feel informal.

The question that must never be answered automatically

"Is this normal?"

It arrives constantly, in many forms. It looks like a question with a stock answer and it is not, because the answer depends on the patient, the procedure, what they are actually seeing, and their history. A system that has learned that most such questions resolve as normal will confidently say so, and it will be wrong in exactly the cases where being wrong matters.

The correct behaviour is to acknowledge, route and be clear about what happens next. Something like: thank you, a member of the team will look at this and come back to you, and if it worsens before then, contact the clinic on this number or use the urgent route.

Two things make that safe. The routing has to reach somebody who is actually available, and the message must not imply reassurance. "That sounds normal but we'll check" has already given the advice.

Designing the escalation

The escalation is the most important part of the build and usually the least designed.

Decide who receives it, by name and role, in and out of hours.

Decide how fast. A clinical escalation sitting in a queue overnight is the failure mode that matters. If nobody is available, the message must say so and give the route that is.

Log every one, with what was said, when it was routed, to whom, and what happened. This is both clinical record and your evidence that the system worked.

Test it regularly, with real phrasings including vague ones. Patients do not write "I am experiencing post-operative bleeding". They write "is it meant to look like this".

Fail towards a person. Anything the system cannot classify goes to a human rather than getting a generic reply.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which treatment triggers which approved sequence, and the rule that anything describing a symptom routes to a person without an answer.
3. Authorize the connections to your practice management system and your WhatsApp Business Platform account.
4. Describe the exceptions explicitly, and be deliberate about the ones that must never be handled automatically.
5. Test the escalation paths with several real phrasings before any patient sees it, and confirm the alert reaches somebody who is actually there.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Consent, and what patients agreed to

Health information is sensitive, and a message about a treatment is health information even when its content is mundane.

Record the channel consent separately from consent to treatment, and record when it was given.

Be clear about what will be sent, and let people opt out of the channel without losing the care.

Assume the device may be shared. Keep clinical detail out of message content where a prompt to contact the clinic would do. A notification preview on a lock screen is visible to whoever is nearby.

Apply your retention policy to messages as well as to records, and decide it deliberately rather than letting a history accumulate indefinitely.

Check what your practice management supplier's terms permit before connecting anything to it.

What goes in the record

If a clinically relevant exchange happens on a messaging channel, it belongs in the patient record, not only in the thread.

That means what the patient reported, when, what was said back, who dealt with it and what was decided. A short note is enough; a thread on somebody's phone is not a record, and it will not be there in five years.

Automate the copying where you can, because a step that depends on somebody remembering during a busy clinic will be skipped and nobody will know which exchanges are missing.

Detail in the message itself

Two competing pressures, and the resolution is a matter of judgement rather than rule.

Specific instructions are followed better than vague ones. Detailed clinical content in a message is also more exposed than the same content in a record, and harder to correct once sent.

The workable position: put the instruction in full, since that is what the patient needs to act on, and keep diagnosis, findings and anything about their broader history out of it. "Keep the area dry until Thursday and take the tablets with food" is instruction. Anything explaining why in terms of their particular case is moving towards the record's territory.

Out of hours, which is when it matters

Most anxious post-treatment questions arrive in the evening, which is precisely when the routing is weakest.

Decide what happens then before launch. Either somebody is genuinely on call and the message reaches them, or the automation says plainly that nobody is available, when somebody will be, and what to do meanwhile including the urgent route.

The failure to avoid is an out-of-hours acknowledgement that sounds like it has been handled. A patient who believes their concern is being looked at will wait, and waiting is the thing the whole design is meant to prevent.

Making it survive

Keep a named clinical owner for every message, with a review date.

Test the escalations monthly, with vague phrasings, whether or not anything changed.

Copy clinically relevant exchanges into the record automatically.

Review the timing against when concerns actually arrive.

Re-check consent and retention when the sequence or the channel changes.

Limits worth knowing about

An automation cannot assess a symptom, and any design that appears to is unsafe.

Sounding reassuring is giving advice, even when hedged.

A messaging platform is not a clinical record system, whatever it can export.

Escalation is only as good as availability. Routing to nobody is worse than not inviting the message.

The channel has its own rules, including that contact outside the 24-hour window needs an approved template, so an urgent proactive message has to have been prepared in advance.

What to settle first

The rule, in writing, agreed with whoever carries clinical responsibility: this automation delivers instructions a clinician approved, and anything describing a symptom goes to a person without an answer. Then build the escalation and test it before writing a single patient-facing message.

Two habits make the difference. Put a clinician's name and a date against every message, because content nobody owns drifts out of date with your name on it. And test the escalation with the words patients actually use rather than the words you would use, since "is it meant to look like this" has to route as reliably as anything more formal.

Frequently asked questions

Can post-treatment instructions be sent automatically?

Yes. Delivering instructions a clinician approved in advance is administration. What cannot be automated is responding to a patient describing their own symptoms, which is clinical judgement.

Where is the line between information and advice?

Information and pre-approved instruction apply to everybody having that treatment. Advice responds to one patient's particular situation, and it belongs with somebody qualified and accountable.

How should "is this normal?" be handled?

Acknowledge, route to a person, and say what happens next and what to do if things worsen meanwhile. Never imply reassurance, since "that sounds normal but we'll check" has already given the answer.

Who should approve the message content?

A named clinician, on a date, with version control and a review schedule. Content whose only approver has left is content nobody is accountable for.

What does a good escalation look like?

A named recipient in and out of hours, a defined response time, every escalation logged, regular testing with vague real-world phrasings, and anything unclassifiable going to a person.

What about consent?

Record consent to the channel separately from consent to treatment, be clear what will be sent, and allow opting out without losing care. Assume devices may be shared and keep clinical detail out of message content where a prompt would do.

Do these exchanges go in the patient record?

Yes, if clinically relevant. What was reported, when, what was said, who handled it and what was decided. Automate the copying, because a manual step during a busy clinic gets skipped.

How much clinical detail should a message contain?

The instruction in full, since that is what the patient must act on. Diagnosis, findings and history belong in the record rather than in a message.

What should happen out of hours?

Either somebody genuinely on call receives it, or the message says plainly that nobody is available, when they will be, and the urgent route. An acknowledgement that sounds like it has been handled makes patients wait.

How often should the sequence be reviewed?

On a schedule with a named owner, and whenever practice or guidance changes. A sequence running unreviewed for years sends outdated instructions carrying your name.

Related reading

• Timing aftercare to when it is wanted
• What you are now holding
• The edge cases that actually matter