Integration technical brief

ModMed Pain Integration: API, EMA Web Automation, and Compliance-Aware Data Handling

ModMed Pain (the EMA Pain Management module plus ModMed PM) powers roughly 2,400 interventional pain practices in the United States. Our integration combines ModMed’s FHIR R4 API with targeted EMA web automation for screens the API does not expose, all wrapped in a compliance-aware boundary that keeps controlled-substance decisions in clinician hands.

FHIR R4 + EMA Automation · Compliance First

Practices Live

2,400

ModMed Pain practices in the addressable footprint

Surface Coverage

FHIR + EMA

Full FHIR R4 plus EMA web automation for non-API screens

Escalation Rate

100%

Controlled-substance requests routed to provider, zero auto-promised

Write Success

99.6%

Successful writes across appointments, intake, and tasks

Product overview

What ModMed Pain Actually Is

ModMed Pain is a specialty configuration of the EMA platform with a Pain Management module sitting on top of ModMed Practice Management. It is purpose-built for interventional pain clinics that perform image-guided procedures, manage chronic opioid populations, and run a heavy compliance workflow (PDMP checks, urine drug screens, controlled-substance agreements). Knowing the product shape drives the integration shape.

EMA Pain Module

Specialty-aware chart with pain-specific assessments, body diagrams, and procedure documentation
Controlled-substance flag, opioid agreement status, and PDMP-check timestamp on every chart
Procedure templates for ESI, facet, RFA, SCS, kyphoplasty, and trigger-point workflows
UDS ordering, results review, and aberrancy flagging integrated with the chart timeline
iPad-first clinical workflow that drives some screens through EMA web rather than FHIR

ModMed PM (Scheduling and Billing)

Provider, room, and equipment-aware schedule templates with procedure-type constraints
Visit reasons mapped to procedure codes that gate which slots are valid
Insurance eligibility, authorization status, and self-pay flags on each appointment
Recall and waitlist tables exposed through PM endpoints and PM screens
Task queues used for UDS scheduling, PA follow-up, and pre-op clearance tracking

Integration architecture

FHIR R4 First, EMA Web Automation Where the API Stops

ModMed exposes a robust FHIR R4 API, but pain-specific screens (opioid agreement uploads, certain PDMP attestations, some procedure-template selection paths) live only inside EMA. We treat the API as the primary surface and fall back to a hardened EMA web automation layer for the rest. Both paths share the same audit log and the same compliance guardrails.

Layer 1: ModMed FHIR R4 API

OAuth 2.0 client credentials, per-practice firm prefix and JWT-signed assertions
Patient, Appointment, Slot, Schedule, Practitioner, Location, Encounter resources
Observation and DocumentReference reads for UDS, PDMP attestation, and agreement uploads
Sandbox tenant for every practice with a synthetic procedure-aware schedule for pre-go-live validation
Webhook receivers for appointment changes so our state mirror stays current without polling

Layer 2: EMA Web Automation

Headed Playwright sessions on dedicated ECS workers with per-tenant session keepers
Covers procedure-template-aware booking screens that FHIR Slot does not enumerate
Reads opioid-agreement and PDMP screens when the equivalent FHIR resource is absent for that tenant
Re-login is single-attempt with permanent lock and Slack alert on failure (no brute retry)
Every action carries the same compliance guard the FHIR path does, no shortcuts in the UI layer

Sandbox Testing Flow

Before any practice goes live, we mirror their procedure templates, provider schedule, and visit-reason map into a ModMed sandbox tenant. Our regression harness then runs 60+ scripted scenarios (new patient booking, recurring injection follow-up, controlled-substance request, after-hours intake, PDMP-flagged caller, etc.) end to end against the sandbox before a single production write is enabled.

Data we read

What the Receptionist Pulls From ModMed

Read access is scoped to exactly what the AI needs to answer the call correctly and route safely. We do not pull full chart contents and we do not cache PHI longer than the call session requires.

Procedure-Aware Appointment Slots

FHIR Slot filtered by visit reason and procedure type
Provider, room, and equipment constraints respected (no booking an ESI into a non-fluoro room)
Pre-op clearance windows enforced where the schedule template requires them
Duration and block rules read directly from the live PM schedule

Controlled-Substance Flags on the Chart

Active chronic-opioid flag and last refill date
Aberrant UDS result flag (not the result itself, just the flag)
Provider-set restrictions on phone-based requests
Used only to route, never to make a clinical decision

Opioid Agreement Status

Boolean active or expired status per patient
Renewal due date for proactive scheduling of an in-person review
Drives whether the AI offers to schedule an agreement-renewal visit
Never read aloud verbatim, never summarized as clinical guidance

PDMP Check Timestamps

Most recent PDMP check date and state of record
Used only to surface to the provider when a refill request comes in
Drives task creation for the clinical team, not phone-side decisions
No PDMP content ever leaves the ModMed boundary

Data we write

What the Receptionist Writes Back to ModMed

Writes are bounded to non-clinical, reception-side surfaces. The AI books, intakes, and creates tasks. It does not touch medication lists, problem lists, or clinical notes.

Appointment Booking by Procedure Type

FHIR Appointment write with the correct visit reason and procedure-mapped duration
Falls back to EMA web booking for templates the API will not accept directly
Insurance, address, and pharmacy fields populated from caller input
Confirmation written back into the call transcript and a copy delivered to the patient

Intake-Form Push

Branded intake link pushed via SMS or email after the appointment is created
DL and insurance card capture flow through the same intake service used across our EMR footprint
Results land back on the chart as a DocumentReference, not a free-text note
Pain-specific intake variants pulled when the visit reason is a procedure consult

UDS Scheduling Tasks

Task created in the ModMed PM task queue when a UDS is due
Assigned to the practice’s designated controlled-substance coordinator
Includes the inbound call reference for provider context
Never schedules the UDS itself, that decision stays with the clinical team

Compliance-aware integration

Hard Boundaries the Integration Will Not Cross

Interventional pain is one of the most regulated specialties in medicine. The integration enforces hard, code-level guardrails that survive prompt-injection attempts, caller pressure, and ambiguous requests. These are not soft prompts, they are structural.

Never Writes Controlled-Substance Rx

The integration has zero write paths into MedicationRequest for controlled substances. The capability simply does not exist in the deployed code. Refill requests become provider tasks, full stop.

Never Promises a Refill

Dialogue is constrained at the pathway level so the receptionist cannot say a refill will happen, cannot give a timeline, and cannot estimate quantity. Every refill turn ends with a provider-task confirmation.

Never Overrides Pain-Agreement Flags

If the chart carries an expired or violated opioid agreement, the booking path for in-office controlled-substance visits is hard-blocked and routed to the clinical team for review.

100% Escalation, Zero Auto-Promised

Across live ModMed Pain deployments, 100% of controlled-substance requests escalate to a provider task with the inbound call context attached. Zero are auto-promised, auto-approved, or auto-answered with a clinical commitment. This is the single most important number on this page.

Audit trail

Per-Call Audit Log With EMA Chart Link

Every call that touches a ModMed Pain chart writes an audit record that the practice can reconcile against the chart in EMA. The record captures what was read, what was written, what was escalated, and the deep link back to the chart.

What the Audit Record Contains

Call ID, caller phone number, and timestamps for every state transition
FHIR resource IDs of every Patient, Appointment, Slot, and Task the call touched
EMA deep link that opens the affected chart in the practice’s EMA tenant
Provider task references with the call transcript attached for context
Compliance-guard hits (which guardrail fired, which dialogue path was blocked)

Where Practices See It

QA dashboard call detail view with one-click EMA chart open
Daily digest email summarizing controlled-substance escalations
Per-call PDF export for medical-record retention if required by state board
Webhook firehose for practices that want audit events in their own SIEM

Go-live timeline

From Sandbox to Production in Three Phases

Sandbox Mirror

Procedure templates, visit reasons, and provider schedule mirrored into a ModMed sandbox tenant. All 60+ regression scenarios run green before phase 2.

Verified read-only, zero PHI risk

Production Read-Only

Production FHIR credentials enabled in read-only mode. AI quotes live availability and live chart context, but writes remain disabled and queued for human review.

Practice signs off on accuracy

Production Write

Writes enabled with the full compliance guard. Sentinel alarms wired for write-success-rate drift, controlled-substance escalation rate, and any guardrail-bypass attempt.

99.6% write success at steady state

Operational hub

ModMed Pain Operational Hub

Looking for the day-to-day operational view (workflows, KPIs, support contacts) instead of the integration shape? The ModMed Pain hub covers the practice-facing side.

Open ModMed Pain Hub

Receptionist for pain practices

AI Receptionist Built for ModMed Pain

The pathway, voice, and compliance posture above are packaged as the ModMed Pain AI receptionist. See the product-side view of what callers experience.

See the Receptionist

Related surfaces