This walkthrough creates a thread through the FHIR API using MedplumClient. That matches how a real app (or Bot) writes messages. The Fanoni EHR is useful as an inspector: confirm resources, references, and history—not as the primary authoring experience you ship to users.
These patterns show how to bridge Fanoni messaging to external channels (SMS, email, push notifications) using Bots and on-demand $execute. For in-platform automations (Tasks, reminders, scheduling), see Messaging Automations.
Communication.payload supports three content types. You can combine multiple entries in a single message.
This page covers two workflows: correcting a message that has already been sent, and saving draft messages before sending. The editing section presents both a compliance-focused retract-and-correct pattern and a simpler in-place update alternative. The drafts section covers browser-only and cross-device persistence strategies.
When messages need responses — and those responses need to be tracked, assigned, and rerouted — use the FHIR Task resource alongside Communication. This separates message content (Communication) from the routing and assignment lifecycle (Task), allowing you to reassign work without modifying conversation data.
The patterns on this page use Fanoni Bots — an advanced feature that is disabled by default on many projects — and FHIR Subscriptions. Recurring automations also use cron-scheduled Bots (Cron Jobs for Bots). Confirm Bots are enabled for your project and that you can create Bots and Subscriptions (typically as a Project administrator).
In a healthcare context, messages are sent all the time and can include many scenarios (patient to physician, physician to physician, and more), so ensuring they are well organized is important. This guide explains how to model and organize threads in Fanoni.
How you track sent, received, and read for messages depends on two things: whether a message can have more than one recipient (group threads), and whether you need to search for unread messages via the API. Use the decision guide below to choose the right model.
Intro
How you populate sender and recipient on the thread header affects these queries. For recommended modeling (including listing the thread creator in recipient), see Building and Structuring Threads.
This guide explains how thread header Communication.status models open versus closed threads, how to manage participants on the header with recipient, and how FHIR access policies align with who should see a thread.