Apptloop Try the demo

The front desk for US dental practices, by text and website chat.

Apptloop answers patients' messages, books, moves and cancels appointments in the practice's real schedule, and flags urgent messages for the team, who see the conversations in one dashboard and can take any of them over.

The demo is for invented data, and deletes itself after 7 days. Apptloop is not yet available for use with real patient information: see Status.

The demo's Today page, with the receptionist panel open on a simulated text. The patient asks for a cleaning tomorrow morning, the assistant offers three checked times, the patient picks the earliest and says yes, and the assistant confirms the booking, which appears in Today at 8:00 AM, booked by SMS.
A simulated text in the demo: checked times, the patient's yes, and the booking in Today. Invented data; nothing is sent.

What the assistant does

Answers by text and on the practice's website

Patients write in a chat window on the practice's own website, or by text message. Texting is built and tested with a simulated SMS provider; connecting a real one is listed under Status. The assistant runs on Claude, by Anthropic.

Books only after a clear yes

It books, moves or cancels only when the patient's next message is a clear yes to exactly that change; then the application itself carries it out. The rule is in the code, not only in the instructions. Free times come from the live schedule, and a reply that names clock times without checking it is held back.

Knows the practice

Opening hours, closed days, services and prices, and the dentists come from the practice's settings. For anything not there, it is instructed to say that a team member will follow up, rather than guess.

Puts emergencies first

A message that reads like an emergency is marked urgent for the team, and the reply opens by telling the patient to call 911 or go to the nearest emergency department. The assistant is instructed not to give medical advice and to refer such questions to the practice.

Hands over to people

The team can take over any conversation and hand it back. The assistant hands one over by itself when a minor seems to be writing alone, or after three failed attempts to confirm who is writing.

Handles a family's shared phone

On a number several patients share, nothing about appointments can be done until the sender says who the message is about. The assistant is not given the names of the others on that number.

The website chat in the demo: a visitor asks for the opening hours and the assistant answers Monday to Friday, 8:00 to 17:00, closed at weekends, from the practice's settings.
The website chat, answering from the practice's settings.

What the practice's team gets

Today

The day's appointments in the practice's time zone: book, move, confirm, cancel, mark a no-show.

Inbox

The practice's conversations, urgent ones first, updated live; take over, write as staff, hand back.

Patients

Search, the patient's record and its history, text-message consent per phone number, clinical notes for clinical roles only, and an export.

Settings and roles

Opening hours, services and dentists; the website chat to embed. Owner, admin, front desk, dentist and hygienist each see what their role needs.

Today: the day's appointments with their status, and buttons to confirm or cancel each.
Today
The inbox, urgent conversations first. The open one, about a swollen face, was flagged urgent and the patient was shown the emergency number.
Inbox
A patient's record: details, text-message consent with its history, and upcoming and past appointments.
A patient's record
Settings: the practice's opening hours for each weekday, in Eastern Time.
Settings

From the demo, with invented data only.

Security: a HIPAA-ready architecture

  • Multi-factor sign-in required on every practice account outside the demo; a session ends after 15 minutes idle.
  • Each practice's data is kept apart by the database itself (row-level security).
  • Changes to patient information, and staff views of records and conversations, are recorded in an audit log that can only grow, with a hash chain that shows any change to it.
  • Clinical notes and messages are encrypted with keys of their own practice.
  • Logs record requests without their contents, with sensitive fields redacted; the demo keeps no visitor's network address.
  • Consent to text messages is recorded per phone number, with its history; STOP is honoured.

HIPAA-ready means these technical safeguards are built in. It is not a claim of HIPAA compliance: no Business Associate Agreement is in place, and compliance also depends on a practice's providers, agreements and policies.

How it is built

  • TypeScript on Node.js, with Fastify, PostgreSQL and React.
  • Runs with Docker on a single server, as the demo does; a production environment on Google Cloud is described in Terraform.
  • More than 600 automated tests, run on every change, and 100 end-to-end browser tests, run on every change to the application.
  • The design decisions written down, with their reasons.
  • Built for dentistry, but not tied to it: another specialty needs its own emergency rules, roles and services, and the steps are documented.

Status

Apptloop runs today as a public demo with invented data. Before it is used with real patients, a deployment needs:

  • an SMS provider connected, and the US registration for business texting (10DLC);
  • Business Associate Agreements with the hosting, SMS and model providers;
  • a production environment, for example the Google Cloud one described in Terraform;
  • an email provider, for password resets;
  • a legal review of the text-message consent wording and of the privacy terms.