How to Automate ModMed

EMA was written one specialty at a time

ModMed, from Modernizing Medicine, is a cloud-based EHR and practice services company built for specialty practices rather than general medicine. Its EHR, EMA, is developed specialty by specialty, with versions for dermatology, orthopaedics, podiatry, ophthalmology, gastroenterology, otolaryngology, urology, pain management and plastic surgery, as well as ambulatory surgery centres.

That is an unusual way to build software and it explains the loyalty. An orthopaedic surgeon and a dermatologist do not document the same way, do not order the same things and do not bill the same codes. EMA is iPad-based and adapts to how a particular physician practises, suggesting the diagnoses and treatments that clinician actually uses.

So a practice on ModMed has the visit itself well covered. The note, the codes, the orders, the schedule and the claim sit together, shaped for the specialty. What that leaves is everything the practice needs from organisations that are not the practice.

The visit ends and the paperwork does not

An orthopaedic practice books an MRI, and the MRI needs prior authorisation. That request goes onto the insurer's portal, sits in a queue somebody else controls, and comes back days later, or does not come back at all.

Multiply it. A brace ordered from a DME supplier with its own site and its own status page. Imaging read by a radiology group whose results land in a portal that never interfaced with anything. A physical therapy referral sent out with no way of knowing whether the patient ever went. A claim denied by a payer, with an appeal window that closes on a date nobody wrote down. A surgery waiting on a date from a hospital that runs its own scheduling system.

Every one of those has somebody in the practice assigned to it, and that person's day is spent in browser tabs belonging to other companies, checking whether anything has changed since yesterday.

ModMed

Authorisations chased before the date Prior authorisation status read from each payer's portal daily, so a delay is caught on day three rather than on the morning of surgery.

Appeal windows that do not close quietly Denied claims collected from payer portals with their deadlines attached, ordered by which window closes first and what the claim is worth.

Loops that actually close Referrals, imaging results and DME orders tracked back to the patient they belong to, rather than waiting for someone to ask about them.

EMA, BOOST and Klara act on the practice's own records

ModMed has built well beyond the chart, and the internal picture is strong.

ModMed Practice Management runs scheduling and the front office. ModMed BOOST is the revenue cycle service working the billing side. ModMed Patient Engagement, powered by Klara, handles two-way messaging with patients and takes a large share of the calls off the desk. ModMed Scribe listens to the visit and drafts the note, suggesting ICD-10 codes as the encounter happens. ModMed Analytics reports on how the practice is performing and benchmarks it against others.

Each of those is good at what it does, and each has the same horizon: the practice's own record, and the channels ModMed built to reach patients.

A payer's authorisation portal is not one of those channels. Neither is the DME supplier's order tracker, the radiology group's result portal or the hospital's scheduling system. They hold the answer to the question the practice keeps asking, which is nearly always the same question: has this been approved yet.

An approval nobody chased is a surgery that slips

The practice finds out late because the question only gets asked when somebody has the time to ask it. Asked every morning, on every portal, the answer arrives with days left to act on it.

Prior authorisations checked daily on each payer's site, with anything still pending after three days flagged for a phone call rather than left to sit. Denied claims collected with their appeal deadlines attached, ordered by which window closes first.

DME orders followed on the supplier's own status page, so a patient promised a brace by Friday hears from the practice before they ring to ask. Imaging results pulled from the radiology portal and matched to the patient booked in on Tuesday. Referral loops closed: the patient sent to physical therapy in March, checked against whether they were ever seen. Post-operative follow-ups nobody booked, listed by how far past the window they are. Tomorrow's schedule with the gaps, the unconfirmed patients and the missing authorisations marked, ready before the doors open.

The boundary in a clinical setting does not move. Gathering information can run unattended. Anything that changes a clinical or billing record, or that reaches a patient, is prepared for a qualified person to review and act on. The judgement stays with the clinician and only the fetching is handed over.

The approvals get chased overnight

Each of those checks is a person opening a browser, signing into somebody else's system, and reading a status that has usually not changed. It is the least skilled and most consequential work in the building.

WebRun is an agent that works a real Chrome browser, signed in as your staff are. It opens ModMed and the payer, supplier and imaging portals beside it, reads what is there, and brings back a worklist with the dates attached.

Sessions stay inside your own private environment and are not shared between tools, a workflow can be locked to an explicit list of domains, and you can watch a run and stop it at any point. Nothing that touches a chart or a patient goes anywhere without a qualified person approving it.

The workflows below are already built, and each one names what it opens.