Building on Lithos, Part 5: wiring clinical events into Slack, your CRM and your support desk

One receiver, then a data rule per tool

Route every Lithos webhook to one receiver you own, then send each tool only the fields it may hold. Slack and a CRM without a BAA get IDs, status and a link to your admin, never clinical detail; a help desk under a BAA gets what an agent needs to answer.

The volume makes the case. At 800 encounters a month you’ll receive 4,000 to 12,000 events, since each encounter throws off five to fifteen. Ops wants a few dozen of them.

This is Part 5 of Building on Lithos. Part 3 on event-driven integration built the receiver; this part is what you do with it.

The receiver’s job is short: check the X-Lithos-Signature header, store the event id, return a 2xx and queue the work. A rule per destination on the queue side decides what to send.

Route the events where a person can still act

Lithos sends events for encounters, care plans, orders, appointments, inquiries and lab requisitions. Most are good news nobody needs to hear. Route the ones where someone can still change the outcome:

• encounter.escalated: the provider paused for more from the patient (patient_information_required). There’s no approval event; sign-off is encounter.completed.
• care_plan.refill_due: a refill date passed. The renewal is a follow-up encounter on the same care plan.
• order.canceled, and orders stuck in processing. order.placed means the pharmacy accepted it; tracking appears when the pharmacy reports it.
• appointment.no_show: a missed live visit.
• inquiry.created: a patient or care-team message.

Keep PHI out of Slack and your CRM

The webhook payload is thin: an event id, a type and the resource id. PHI leaks later, when your receiver copies fields into tools outside your PHI boundary. Write the rules down per destination.

Two traps. Category is PHI: a CRM contact tagged “weight management: active” discloses health information, so use a neutral “member: active”. HIPAA and your marketing stack covers the CRM side. Slack is durable: messages get searched, exported and screenshotted, so post a link to your logged admin tool instead of the detail.

Write the routing table as data

The 24-hour, 48-hour and 3-day thresholds are assumptions to tune, not Lithos service levels. The ageing rules aren’t events: they’re timers your receiver starts on one event and clears on the next.

Act on current status, not the event type

Lithos webhooks arrive at least once and in no guaranteed order.

Duplicates: store each event id under a unique constraint and skip repeats. Then make each downstream write idempotent, because your fan-out retries too: key tickets on resource ID plus reason and CRM updates on contact ID plus stage. See idempotency key for the pattern.

Ordering is the one that bites. order.completed can arrive before order.placed. If the event type drives state, the late placed drags a shipped order backward, and support tells a patient it’s “with the pharmacy.”

So fetch the resource and act on its status. A minimal handler (field names abbreviated; check the API reference you get with sandbox access):

export async function handle(rawBody, headers) {
  verifySignature(rawBody, headers["x-lithos-signature"]); // throws on mismatch
  const event = JSON.parse(rawBody);

  if (!(await db.insertEventIdIfNew(event.id))) return; // duplicate delivery

  const resource = await lithos.get(resourcePath(event)); // fetch on receipt
  for (const rule of routes.filter(r => r.matches(event.type, resource))) {
    await queue.enqueue({
      destination: rule.destination,
      dedupeKey: `${rule.name}:${resource.id}`,
      payload: rule.minimize(resource), // per-destination PHI filter
    });
  }
}

Each rule’s minimize is the PHI table in code. For Slack it returns an internal order ID, the status and an admin URL, nothing more. In production, acknowledge once the event is stored and do the fetch from the queue, so a slow CRM never triggers retries.

Test five cases in the sandbox

Sandbox routes drive encounters, orders and inquiries through their statuses, and a test clock moves time for the timer rules.

1. Escalate, then complete, one encounter. One ticket opens and closes.
2. Deliver the same event twice. One Slack post.
3. Deliver order.completed before order.placed. The CRM ends in the right stage.
4. Advance past a refill date with no follow-up. The outreach task appears.
5. Search every non-BAA destination for names, emails and treatments. Find none.

Alert on exceptions, summarize the rest

A noisy channel gets muted, and then everyone assumes someone else is watching. Give every routing row an owning team and delete rows nobody owns. Post exceptions and ageing; send counts as one morning summary with links to filtered admin views. If you’re sizing the team behind the tickets, see patient support for telehealth programs.

Keep the routing table as compliance documentation. When a tool joins, ask which PHI column it sits in and whether you have a BAA. Reviewers ask for it; answering the security questionnaire shows where it fits.

Frequently asked questions