Dermatology Practice Software: The Multi-Location Operator's Build Guide

Why practice software makes or breaks a dermatology group

You run 9 clinics. Six of them are medical derm with a heavy Mohs and general surgery load, three are hybrid medical plus cosmetic with laser and injector chairs that bill nothing through insurance. Your EMR is ModMed EMA on most sites, and the two practices you acquired last year are still on Nextech because the migration quote came back at six figures and nobody wanted to fight it. Your path goes to Quest for the routine cases and a regional dermatopathology lab for the tricky ones. Your cosmetic side runs on a mix of Aesthetic Record and one office that never gave up its Boulevard booking. Revenue reporting means someone in the back office exporting from three systems into a workbook every Monday.

The scene that costs you money looks like this. A patient gets four lesions biopsied on a Tuesday at the Westside office. The MA logs them in EMA with the body map, sites A through D. Path comes back nine days later: site C is a basal cell, sites A, B, D benign. The result lands in the EMA inbox of the provider who did the biopsy, except she is now at a different location three days a week, and her inbox has 60 unread results. She signs it. The patient never gets called because the callback lives in a shared task list that the front desk at Westside checks and the front desk at Northgate does not. Six weeks later the patient calls asking about a spot that is bigger now. Someone opens the chart, sees the BCC, and now you have a real problem: a nine-week gap between diagnosis and treatment on a documented malignancy, no defensible audit trail of who was supposed to call, and a patient who is going to tell that story.

That gap is not rare. Across the derm groups we have worked with, when we run the query against their own data, somewhere between 3 and 8 percent of positive biopsies have sat past 14 days without documented patient contact. At 12,000 biopsies a year that is 360 to 960 cases. Most of them close eventually. The ones that do not are the ones that end up in front of a lawyer. Meanwhile your practice manager spends 6 to 9 hours a week rebuilding the same cosmetic revenue report because nothing in your stack knows that the Botox appointment and the skin check appointment belong to the same human being.

Problem 1: the biopsy loop is not a loop, it is a pile

Every derm EMR has a path tracking module. ModMed has one. Nextech has one. EZDERM has one. They all model the same thing: a specimen goes out, a result comes in, a provider signs it. What none of them model is the obligation that a positive result creates. Nothing in the software knows that a BCC on the nose of a 71 year old means call within 48 hours, schedule Mohs within 30 days, and if the patient does not answer, try twice more and then send a certified letter.

The workaround every group runs is a spreadsheet. Someone, usually a lead MA or the clinical director, keeps a biopsy log. Specimen ID, date out, date in, result, called yes or no, scheduled yes or no. It works until you have 9 locations and 14 providers, at which point you have either one spreadsheet nobody owns or nine spreadsheets that disagree. And the log has no link back to the chart, so reconciling it against what the EMR actually says is a manual exercise nobody does.

The custom build treats a biopsy as a state machine with a clock on every transition rather than as a document. You define the states: collected, in transit, resulted, reviewed, patient contacted, treatment scheduled, treatment completed, closed. Each transition carries an SLA that varies by diagnosis: melanoma gets a 24 hour contact clock and escalates to the medical director if it breaches, a benign nevus closes automatically on result. The specimen record links to the lesion record, which links to the body map coordinate, which links to the patient. When path posts a result, the system parses the diagnosis line and routes accordingly. Document extraction does real work here: path reports come back as PDFs or as HL7 with the actual diagnosis buried in free text narrative, and a model that reads the report and pulls out diagnosis, margin status, Breslow depth, and site correlation beats a regex and beats an MA reading 60 reports a day. You do not let it auto-close anything. You let it classify, pre-populate, and flag the disagreements where the report says site C and the requisition says site B, which happens more than any pathologist wants to admit. A derm group we built this for went from a biopsy log nobody trusted to a dashboard where the clinical director sees every open specimen past SLA across all sites on one screen, and the past-14-day count went from a number nobody knew to a number the medical director looks at every Monday.

Problem 2: lesions have history, EMR notes do not

A patient has a mole on her left scapula. She has been seen 6 times over 4 years. Three different providers have looked at that mole. Two of them photographed it. One measured it at 5mm, another wrote "unchanged." The photos are in the EMR, attached to encounters, which means comparing 2022 to 2026 requires opening two encounters in two tabs and eyeballing two images shot at different distances with different lighting on different phones.

This is the biggest structural gap in off-the-shelf derm software, and it follows from the data model rather than from carelessness. EMA and Nextech are encounter-centric because billing is encounter-centric. The lesion is not a first class object. It is a coordinate scribbled on a body map inside one note. There is no primary key for "the mole on her left scapula" that persists across visits, so there is nothing for a photo, a measurement, a biopsy, or a diagnosis to attach to over time. Total body photography systems like Canfield VECTRA solve imaging but sit as their own island, and at six figures per unit you are not putting one in nine offices.

What a custom build does: create the lesion entity. It has a stable ID, a body map coordinate with a laterality and an anatomic region code, and a timeline. Every photo, measurement, dermoscopy image, biopsy, and diagnosis attaches to it. The provider opens the patient and sees, per lesion, a horizontal strip: 2022 photo, 2024 photo, 2026 photo, side by side, with the measurements underneath. Photo capture goes through a phone app with a scale marker so the images are actually comparable, which is boring plumbing and matters enormously. You are not building an AI diagnostic tool. You are building the thing that lets a human make the comparison in 4 seconds instead of 4 minutes, on a patient with 30 tracked lesions. The reads-in-context part, where a model flags that a lesion grew 2mm and changed border since the last visit, is a queue-ranker rather than a diagnosis, and you present it as such. Everything writes back to the EMR as a structured note so your billing and your legal record stay where the compliance people expect them.

Problem 3: cosmetic revenue is invisible until it is gone

Your medical side is measured to death because insurance forces it. Your cosmetic side, which is likely a fifth to a third of your revenue and carries a much higher margin, is measured by whatever Aesthetic Record's dashboard happens to show, per location, with no connection to the medical chart. You cannot answer basic questions. How many of our cosmetic patients came from a medical skin check? What is the 12 month value of a patient who starts with a mole check versus one who walks in for Botox? Which injector has the best retention? Which of our Kybella package holders have unused sessions expiring?

The reason this is unfixable off the shelf: your cosmetic system and your EMR do not share a patient identity. Same person, two records, no link, and the cosmetic system will not join to your medical data because it was never designed to be a subordinate system in a group. Aesthetic Record is built for the medspa that only does cosmetic. Nextech has a cosmetic module and it is genuinely better here than ModMed, but the reporting stops at the location boundary and the package logic breaks the moment a patient wants to use sessions at a different office.

The build: a patient identity resolution layer that matches across systems on name, DOB, phone, and email with a human review queue for the fuzzy matches. Then a unified ledger where a Botox unit, a laser session, a Mohs stage, and an E/M visit all land as line items against one patient. Now the questions answer themselves. Package liability becomes a real number on a real dashboard: total unredeemed sessions on the books, the slice expiring inside 90 days, and the named list of patients to call this week. Provider dashboards show revenue per chair hour by location for both lines, which is the number that drives your scheduling decisions and is currently something you guess at. Forecasting on top of that is honest and useful: cosmetic demand is seasonal and event-driven, and a model trained on your own 3 years of booking data will predict December and pre-wedding-season load better than your practice manager's memory. Use it to staff injectors, not to make clinical calls.

Problem 4: nine locations, one phone tree, and a booking process that leaks

A patient calls Tuesday at 6:40pm wanting a skin check. Nobody picks up. She leaves a voicemail. Wednesday morning someone at Northgate listens to it, calls back, gets voicemail, leaves a message. Thursday she calls back, gets a different person, and books 7 weeks out at the only location with availability, which is 40 minutes from her house. Meanwhile Westside had a same-week cancellation slot and Eastside had two openings Friday. Your online scheduler, whether it is the ModMed patient portal or a Zocdoc listing, shows a slice of availability that is intentionally conservative, because letting patients book real slots into a derm schedule without triage produces chaos: someone books a 10 minute follow-up slot for a full body check with 20 suspicious lesions.

Off-the-shelf cannot solve this because the constraint is your rules, not the calendar. A full body skin check with a history of melanoma needs 30 minutes with an MD, not a PA. A Botox touch-up needs 15 with the injector who did the original. A post-Mohs check needs to be at the surgical site's location. No generic scheduler encodes that, and your front desk encodes it in tribal knowledge that walks out the door with turnover.

What we build: a triage-and-book flow, on the phone and on the web, that asks the 5 questions determining visit type and duration, then searches availability across all locations within the patient's radius and books the right slot with the right provider. After hours, an AI voice intake handles the 6:40pm call: it asks the same 5 questions, checks insurance eligibility against your payer list, offers the three best slots, and books. Not a chatbot that says someone will call you back. An actual booking, into your actual schedule, with the triage rules applied. The cases it cannot handle, and there will be some, it escalates with a full transcript so the morning callback starts from information instead of a voicemail. The measurable outcome is the after-hours and weekend call volume that currently becomes a callback pile, and the cancellation slots that currently go empty because filling them requires someone to manually work a waitlist.

Problem 5: you cannot compare your own locations

Your Westside office does 38 patients a day per provider. Northgate does 24. Is Westside better run, or is Westside seeing easier patients, or does Northgate have a provider problem, or is Northgate's MA staffing wrong? You do not know, because the data to answer it lives in EMA's reporting module which reports by provider and by location but cannot slice by visit complexity, and your two Nextech offices are not in that report at all.

This is the acquisition tax and it is why groups build. Every practice you buy comes with its own EMR instance, its own templates, its own way of coding a skin check. ModMed will happily sell you migration services. That does not merge the history, and it does not make 2023 Nextech data comparable to 2026 EMA data. A custom read layer does: nightly extracts from every source, normalized into one schema where a visit is a visit and a biopsy is a biopsy, with the mapping rules written once and versioned. You keep the EMRs. You stop pretending they will ever agree. The group dashboard then does the thing you want: per location, per provider, visits per session, biopsy rate, positive rate, cosmetic attach rate, no-show rate, days-to-third-available. When you buy practice number 10, you write one mapping and it appears in the dashboard in a week instead of a quarter.

What this costs and how long it takes

These are Digital Heroes numbers, from delivery across 2,000+ projects. A focused first release, meaning one problem solved end to end for the whole group, runs $60k to $130k and ships in 12 to 16 weeks. For derm the highest-value first release is almost always the biopsy-to-closure tracker with path extraction, because it has the clearest risk story and it forces you to solve patient identity and EMR integration early, which everything else needs. The full platform, meaning lesion timeline, cosmetic ledger, triage booking, and the group dashboard across all sites, runs $150k to $400k phased over 6 to 12 months.

What pushes you toward the top of the band in this category. Number of EMR instances: one ModMed tenant is straightforward, while ModMed plus Nextech plus a legacy EZDERM instance from an acquisition is three integrations and three data models and roughly double the integration work. Path lab count: Quest and LabCorp have documented interfaces, your regional dermatopathology lab probably sends PDFs by fax into a Hyland OnBase queue and that costs real money to handle well. Image volume and storage: total body photography and dermoscopy at scale means terabytes with HIPAA retention rules, and you decide early whether photos live in your build or stay in the EMR, because moving them later is expensive. Cosmetic package logic: simple prepaid session counts are cheap; memberships, tiered pricing, per-injector commission, gift cards, and cross-location redemption is a small product on its own. And BAAs plus a HIPAA security risk assessment plus audit logging on every PHI read is 3 to 5 weeks of work you budget rather than discover in week 14.

What we do not do: quote you a full platform before we have looked at your actual path report formats and pulled a sample of your EMA data. The estimate before that conversation is a guess and everyone knows it.

Build versus buy, and where the line actually is

Buy, and stop reading here, if you run 1 to 3 locations on one EMR with one path lab and either no cosmetic line or a cosmetic line under 15 percent of revenue. ModMed EMA is a genuinely good product for that practice. Its body map is fine, its path module works when one clinical lead can hold the whole biopsy pile in their head, and its per-provider monthly price is cheaper than anything you would build. If that is you and you are frustrated, your problem is workflow discipline rather than software. Fix the workflow. We will tell you that on the call and not charge you for it.

Build when you hit these signals, and you will recognize them. First: you have more than one EMR and no plan to consolidate, because the migration quote is worse than the pain. Second: your biopsy tracking lives in a spreadsheet that a specific human owns, and you have quietly worried about what happens when that human leaves. Third: someone spends 5+ hours a week producing a revenue report by hand, which at a practice manager's loaded cost is real salary spent rebuilding a report that is always four days stale. Fourth, and this is the one that decides it: you are acquiring. If you buy two practices a year, every year you stay on stitched-together off-the-shelf the integration debt compounds, and the day you want to sell to a PE buyer they will ask for group-level operational data you cannot produce. That is a valuation problem by then, not a software problem.

The position we take: do not replace your EMR. It is where your billing lives, your payers are integrated with it, and rebuilding an EMR is a seven-figure mistake we have watched other groups make. Build the layer above it that your EMR was never designed to be: the lesion timeline, the biopsy state machine, the unified patient ledger, the group dashboard. Read from the EMR, write structured notes back to it, and let it keep doing the job it is good at.

How to choose a developer for dermatology practice software

Ask them to draw your data model on a whiteboard before they quote. Specifically: how do they represent a lesion that persists across encounters? If the answer involves attaching photos to visits, they have not built this before and you will pay for their education. The lesion-as-entity versus encounter-as-entity distinction is the whole category. It should take them 90 seconds and they should already have opinions about anatomic region coding.

Ask what they have integrated with, by name and by method. ModMed has an API, and it has limits and quirks that anyone who has shipped against it can describe in detail. Nextech is different. Ask specifically about path: HL7 ORU inbound, the difference between a discrete result and a narrative report, and what they do when the lab sends a PDF. If they say they will build a connector, ask how many they have built. The honest answer includes a story about a lab that would not cooperate.

Ask who signs the BAA, where PHI lives, and to see an audit log design. Not a compliance certificate, an actual design: who read which chart when, retained how long, queryable by whom. Then ask what happens to photos, because derm PHI is disproportionately imaging and imaging is where retention and access control get expensive. If they have not thought about photo access control separately from record access control, they have not built healthcare software.

Get the code ownership answer in writing before the SOW. You own the repository, the infrastructure accounts are in your name, and there is a documented handover. In this category specifically, ask what happens to the mapping rules between your EMRs and their schema, because that is the asset with the most institutional knowledge in it and the thing that hurts most to lose. If a vendor is cagey about ownership, that is the whole answer.