DoctorConnect / Developers
Private Pilot — Pilot Clinics 111 & 501

Patient engagement, as an API.

DoctorConnect AI Agent Gateway exposes 30+ years of patient-engagement infrastructure through OAuth 2.1, MCP, and REST — so AI assistants and partner systems can drive scheduled messaging, secured 2-way text, surveys, recare, appointment reminders, waitlist fill, and patient intake without rebuilding any of the HIPAA-compliant plumbing underneath.

30+
Years in healthcare IT
150+
EHR & PMS integrations
500+
Active medical practices
0
HIPAA violations, ever

Why build patient engagement when DoctorConnect already has it?

Patient engagement is one of those problems that looks simple from the outside and eats years from the inside. Patient consent flows. Carrier opt-in. SMS short-code registration. Voice telephony. HIPAA. BAAs. Multi-tenant scoping. EHR write-back. We finished those battles 25 years ago and have been compounding the integrations ever since.

If you build it yourself

  • 12–24 months building HIPAA-compliant infrastructure
  • Twilio / Telnyx / payer-carrier negotiations and short-code approval
  • Per-EHR integration work for eClinicalWorks, NextGen, athenahealth, AdvancedMD — each its own quirks
  • Audit logging, BAAs with every subprocessor, SOC 2 evidence collection
  • Bounce, opt-out, quiet-hours, rate-limit logic across SMS / voice / email channels
  • A compliance team to keep it all current

If you connect to DoctorConnect

  • OAuth 2.1 token from a clinic that’s already using DoctorConnect
  • Call messages.send_sms, appointments.confirm, or any of the verbs in the next section
  • DoctorConnect handles delivery, retries, opt-outs, quiet hours, EHR write-back, and audit logging
  • Inherit 30+ years of HIPAA-compliant infrastructure on day one
  • Inherit 150+ EHR/PMS integrations on day one
  • Build agent UX, not engagement plumbing

Patient engagement, as an API

Eight capability surfaces exposed through MCP and REST. Each one wraps an existing DoctorConnect product that’s in production today — the gateway adds OAuth scopes, rate limits, and audit logging on top. Status badges indicate which tools are live in Phase 1 read-only versus coming in Phase 2 (write + webhooks).

1. Scheduled messaging

Phase 2

Schedule SMS, voice, or email to a patient on your timeline. DoctorConnect handles delivery, retries, quiet-hours enforcement, opt-out propagation, and per-channel carrier compliance. Your agent decides what and when; the platform handles the how.

  • messaging.send_smsSingle SMS to one patient by id, MRN, or last-4 phone
  • messaging.send_emailTemplated email with merge fields and tracking
  • messaging.scheduleQueue a message for future delivery; respects clinic quiet hours
  • messaging.bulk_sendCampaign send to a filtered patient list (rate-limit gated)
  • messaging.predefined_listPull the clinic’s approved message templates
POST /v1/messaging/send_sms
Authorization: Bearer eyJ...
{
  "patient_id": "p_2k7f...",
  "template_id": "tmpl_visit_followup",
  "variables": { "next_appt": "Tue 9am" },
  "send_at": "2026-05-02T14:00:00Z"
}

2. Secured 2-way messaging

Phase 1 read Phase 2 write

HIPAA-compliant 2-way text threads between staff and patients, with a triage queue, read/unread state, assignment, and AI-assist annotations. Read the queue, mark messages, claim or assign threads, and (Phase 2) reply on behalf of staff.

  • messages.listRecent messages, paginated, filterable by direction or thread
  • messages.unread_countInbox badge counter for staff-side dashboards
  • messages.mark_readMark a thread or message read
  • messages.triage_acceptPull a triage-queued message and start working it
  • messages.assignAssign a thread to a specific staff user
  • messages.delivery_statusFinal delivery state for any sent message
GET /v1/messages?direction=inbound&unread=true&limit=50
Authorization: Bearer eyJ...

{
  "messages": [
    {
      "id": "msg_...", "thread_id": "thr_...",
      "patient_id": "p_...", "channel": "sms",
      "direction": "inbound", "received_at": "...",
      "preview": "I need to reschedule my Thursday..."
    }
  ],
  "next_cursor": "..."
}

3. Patient surveys

Phase 2

Trigger AI-summarized post-visit surveys (NPS, CG-CAHPS, custom), pull responses, and turn high-rating patients into Google reviews automatically. Subscribe to completions via webhook so your agent can act the moment a patient flags a dissatisfaction signal.

  • surveys.sendQueue a survey to a patient over their preferred channel
  • surveys.list_responsesPull responses with score, free-text, and AI summary
  • surveys.get_responseFull detail for a single response, including AI sentiment
  • surveys.summarizeAI-summarized roll-up by provider, location, or period
  • surveys.subscribe_webhookGet notified on every completion (signed HMAC-SHA256)
POST /v1/surveys/send
Authorization: Bearer eyJ...
{
  "patient_id": "p_...",
  "template": "post_visit_nps",
  "delay_minutes": 60,
  "channel": "sms"
}

4. Recare / Recall messaging

Phase 2

Rule-driven outreach for overdue patients. Match on diagnosis codes, time-since-last-visit, custom fields, or any combination — then trigger SMS, email, or voice on the schedule the rule defines. Read existing rules, create new ones, or pull the current overdue list and roll your own outreach.

  • recare.list_rulesAll recare rules currently active for the clinic
  • recare.get_ruleDetail for a specific rule including match criteria
  • recare.create_ruleDefine a new rule programmatically (subject to scope)
  • recare.list_overduePatients currently flagged overdue by any active rule
  • recare.triggerManually fire a rule for a specific patient or cohort
GET /v1/recare/list_overdue?rule_id=rule_diab_a1c
Authorization: Bearer eyJ...

{ "patients": [
    { "patient_id": "p_...", "last_visit": "2025-08-14",
      "days_overdue": 89, "matched_criteria": ["A1c > 9", "T2DM"] }
  ] }

5. Scheduled appointment reminders

Phase 1 read Phase 2 write

DoctorConnect already runs appointment reminders for hundreds of practices. The gateway lets your AI agent layer on top — pull the unconfirmed list, confirm on a patient’s behalf when they reply via your interface, queue no-show follow-ups, or notice patterns nobody else can see.

  • appointments.listFiltered list (date, provider, location, status)
  • appointments.unconfirmedJust the appointments still awaiting confirmation
  • appointments.confirmRecord a confirmation through any channel (Phase 2)
  • appointments.mark_no_showMark a no-show, optionally trigger no-show messaging
  • appointments.queue_no_show_messagesSend the clinic’s configured no-show follow-up
  • appointments.appointment_typesPractice’s appointment-type catalog with durations
GET /v1/appointments/unconfirmed?date=2026-05-02
Authorization: Bearer eyJ...

{ "appointments": [
    { "id": "apt_...", "patient_id": "p_...",
      "provider_id": "prv_...", "starts_at": "...",
      "appointment_type": "Annual Wellness",
      "reminder_attempts": 2 }
  ] }

6. Reminder & message status

Phase 1

Cradle-to-grave delivery status for every reminder, survey, recare blast, or 2-way message. Know if the patient saw it, when, on which channel, and whether they responded — per-message and rolled up.

  • messages.delivery_statusFinal state by message id (sent, delivered, failed, opted-out)
  • messages.listAll messages with delivery status filterable by date and channel
  • reports.confirmation_chartAggregate confirmations by method (SMS, voice, email, manual)
  • reports.communication_summaryVolume + outcomes by channel for any period
  • webhooks.message.deliveredPush notification on each delivery (Phase 2)
  • webhooks.message.failedPush notification with failure reason (Phase 2)
GET /v1/messages/msg_92b.../delivery_status
Authorization: Bearer eyJ...

{ "message_id": "msg_92b...",
  "channel": "sms",
  "status": "delivered",
  "queued_at": "2026-05-01T08:00Z",
  "delivered_at": "2026-05-01T08:00:14Z",
  "carrier": "T-Mobile",
  "patient_replied": false }

7. Fill empty appointment slots (waitlist)

Phase 2

A cancellation comes in. Your agent texts the waitlist. The first patient to claim the slot wins it; everyone else gets a polite “already filled” reply. The EHR is updated. Your agent moves on. The whole loop runs in DoctorConnect’s waitlist engine — you just trigger it.

  • waitlist.listCurrent waitlist entries, paginated
  • waitlist.add_patientAdd a patient with their preferences and constraints
  • waitlist.remove_patientRemove (e.g., after they get scheduled elsewhere)
  • waitlist.trigger_matchFire the match engine for an open slot
  • waitlist.view_claimSee which patient claimed which slot
  • webhooks.waitlist.claimedPush notification on claim (Phase 2)
POST /v1/waitlist/trigger_match
Authorization: Bearer eyJ...
{
  "appointment_type": "Annual Wellness",
  "provider_id": "prv_...",
  "slot_starts_at": "2026-05-03T14:00Z",
  "slot_duration_minutes": 30,
  "max_candidates": 25
}

8. Patient intake forms

Phase 1 read Phase 2 write

DoctorConnect’s digital intake is mobile-first, SMS-delivered, and writes back to the EHR for 150+ supported systems. Send a form to a patient, watch for the completion event, pull the structured submission, and (if you want) use the EHR-Lite AI to validate the responses before they hit the chart.

  • forms.list_submissionsFilterable by date, status, patient, or form type
  • forms.get_submission_detailsStructured field-by-field submission data
  • forms.send_to_patientPush a form by SMS or email (Phase 2)
  • forms.get_pdfFinal PDF for chart attachment
  • forms.batch_downloadMulti-submission PDF bundle
  • forms.mark_doneClose out a submission once reviewed
  • webhooks.form.submittedPush notification on completion (Phase 2)
POST /v1/forms/send_to_patient
Authorization: Bearer eyJ...
{
  "patient_id": "p_...",
  "form_id": "frm_new_patient_intake",
  "channel": "sms",
  "due_at": "2026-05-02T08:00Z"
}

Full OpenAPI 3.1 specification publishes at GA. Phase 3 expands into eligibility verification (Stedi 270/271), telehealth control, and a partner-developer self-service portal.

Two surfaces, one tool layer

Every capability above is reachable from both surfaces. Each surface has its own auth model, rate-limit profile, and consent flow.

Surface A — Clinic-Operator

AI assistants acting on behalf of one clinic user

A staff user’s AI assistant (Claude Desktop, Cursor, internal tools) connects via OAuth 2.1 Authorization Code + PKCE. The clinic and user are resolved from the token, never from a parameter.

  • “Summarize today’s no-show list”
  • “Draft a recall campaign for diabetics overdue for A1C”
  • “Triage the unread messaging queue”
  • “Find appointments where eligibility failed and queue follow-ups”
Surface B — Partner / EHR

External systems acting under per-clinic delegation

A partner system (referring practice, EHR vendor, marketing platform) authenticates with OAuth 2.1 client credentials, then operates against any clinic that has explicitly granted it access through Connected Apps.

  • EHR vendor: bidirectional appointment + form sync
  • Referring clinic: send a referral packet that lands cleanly in DC
  • Marketing platform: subscribe to delivery webhooks for campaign attribution
  • Telehealth partner: pull the day’s telehealth roster

How auth works

Full OAuth 2.1. Authorization Code + PKCE for user-bound flows. Client credentials for partner-bound flows. Token introspection (RFC 7662) and revocation (RFC 7009) endpoints provided. The gateway never accepts a clientid as a tool argument — every call’s tenant scope comes from token claims, enforced in middleware before the tool runs.

# Surface A — clinic-operator OAuth 2.1 flow (high level)
1. AI client opens https://agent.doctorconnect.net/oauth/authorize?...
2. Browser flows to DoctorConnect login (with the user's existing 2FA)
3. Consent screen lists scopes — including the optional pii:names checkbox
4. Code → token exchange → access_token (90d) + refresh_token (1y)
5. Subsequent calls: Authorization: Bearer <access_token>

The pii:names scope. Patient first/last name lookups require an explicitly-granted scope, separate from read:patients. Default token issuance does NOT include it. Identifier-based workflows (id, MRN, last-4 phone) cover the vast majority of agent use cases without ever exposing names to a model.

HIPAA & multi-tenant security

DoctorConnect has shipped HIPAA-compliant software since before HIPAA had a final rule. The gateway inherits the same posture and adds a layer of LLM-specific guardrails.

Tenant isolation in middleware

Every tool implementation calls require_clientid(token) — the effective clientid comes from token claims, never from a parameter. This removes the “AI accidentally cross-tenants by passing a different clientid” failure mode entirely.

PHI minimization by default

Patient names are gated behind the pii:names scope. Default token issuance is read-only and does NOT include it. Identifiers cover most agent use cases without ever exposing patient names to an LLM transcript.

Audit log on every call

Every authenticated call writes a row to the audit log: token id, clinic, user or partner, tool name, redacted args, outcome, latency, IP. Six-year retention — the HIPAA minimum.

Rate, size, and scan limits

Per-token, per-tool rate limits. 100-row pagination cap, 256 KB output cap, date-range required for any list older than 90 days. Every query lists explicit columns (no SELECT *) and is parameterized.

Roadmap

Phased delivery, with each phase ending in a HIPAA review and an internal documentation update. We ship security and tenant isolation before tools, and read tools before write tools.

Phase 0 / 1 Now

Foundations + Read Surface

OAuth 2.1, audit log, tenant guard, MCP wrapper. Read tools across appointments, messages, forms, calendar, providers, reports. Pilot with two friendly clinics. Connect-your-AI page in DoctorConnect Settings.

Phase 2 Next

Write Tools + Surface B

Scheduled messaging, surveys, recare triggers, waitlist, intake form delivery, appointment confirmation. First external partner. Per-clinic delegation UI in Connected Apps. Outbound signed webhooks with retry + DLQ.

Phase 3 Later

Productize + Scale

Eligibility verification, telehealth control, tier pricing, self-service partner onboarding, public OpenAPI spec, status page, SLA. Surface C (patient agents) discovery — gated on a real identity story.