Dermatology Practice Software Problems: The 7 That Lose Biopsies, Cosmetic Revenue and Provider Hours

Why does the biopsy follow up loop fail so often?

Because every dermatology electronic medical record (EMR) models the specimen and none of them model the obligation. ModMed, Nextech and EZDERM all have path tracking: a specimen goes out, a result comes in, a provider signs it. Nothing in that chain knows that a basal cell carcinoma on the nose of a seventy one year old means call within forty eight hours, schedule surgery within thirty days, and if the patient does not answer, try twice more and then send a letter.

So the practice invents a spreadsheet. A lead medical assistant or the clinical director keeps a biopsy log with specimen identifier, date out, date in, result, called yes or no. It works at one site with one owner. At nine sites and fourteen providers you have either one log nobody owns or nine logs that disagree, and none of them link back to the chart, so reconciling the log against what the EMR actually says is a manual exercise that never happens.

The fix is to model the biopsy as a state machine with a clock on every transition: collected, in transit, resulted, reviewed, patient contacted, treatment scheduled, treatment completed, closed. Each transition carries a service level that varies by diagnosis, so melanoma escalates to the medical director on breach while a benign nevus closes on result. Specify those states and clocks with your clinical leadership before anyone designs a screen, because the escalation rules are the product and the screens are decoration.

What goes wrong when you migrate the biopsy log and the photo archive?

Two migrations run in parallel here and both have a nasty surprise in them.

The spreadsheet migration is the uncomfortable one. Loading historical log rows and matching them back to specimen identifiers in the EMR forces a reconciliation nobody has done, and the output is a list of positive results with no documented patient contact. In the groups we have run this query against, that number is always higher than the leadership expected. Budget a week of clinical staff time to work the backlog before go live, because the new system will surface all of it on day one and you would rather find it in a project than in a deposition.

The photo migration is the expensive one. Dermatology protected health information is disproportionately imaging, and images arrive from phones, dermoscopes and total body photography systems at inconsistent distances, lighting and scale. Migrating them without a scale reference or an anatomic anchor produces an archive you can browse but cannot compare, which defeats the purpose. Decide early whether photos live in the new system or stay in the EMR, because moving terabytes later is a project of its own. And decide the retention rule at the same time, since imaging retention and access control cost real money at volume.

Why do the path lab and EMR integrations break after launch?

Because the interface you tested is not the interface you will receive. Quest and LabCorp have documented interfaces and behave. The regional dermatopathology lab your Mohs surgeon prefers very likely sends a scanned document into a fax queue, and that document contains the diagnosis in narrative prose rather than a discrete field. Any build that assumes structured results across all labs will work in testing and fail in the second month.

Three specific breakages recur. The site letter mismatch, where the report says site C and the requisition says site B, which happens more often than anybody wants to admit and must be surfaced as a disagreement rather than silently accepted. Narrative variation, where the same lab changes report layout and a rule based parser stops finding the margin status. And identifier drift, where a lab reissues a corrected report under a new accession number and your system treats it as a second specimen.

The concrete fix is extraction plus disagreement flagging, never auto closure. A model reads the report and pulls diagnosis, margin status, depth where relevant and the stated site, then pre populates and routes by urgency. Where the extracted site does not match the requisition, or confidence is low, it goes to a human queue. On the EMR side, ask any developer for the specific limits of the ModMed application programming interface by name, because anyone who has shipped against it can describe them in detail and anyone who has not will discover them in week nine.

What happens when photo access control and audit logging are not covered?

This is the compliance gap that most dermatology builds get wrong, because teams treat images as attachments to records rather than as records in their own right. A chart level permission model then grants photo access to everyone who can see the encounter, which in a nine location group is a very large number of people, and the audit log records that a chart was opened rather than that a body image was viewed.

Practical consequences follow quickly. A staff member browsing images they have no clinical reason to see is invisible. A patient asking who has viewed their photographs cannot be answered precisely. And a breach assessment cannot scope the imaging exposure, which is the part patients care about most.

What to require instead:

• Separate access control for imaging from record access, with a clinical reason attached to the view where the image is not part of the current encounter.
• Audit logging on every image read, retained, queryable, and reportable per patient.
• A signed business associate agreement covering wherever the images physically live, including any storage or processing service in the chain.
• A written retention and disposal rule, because indefinite retention of body imaging is a decision, not a default.

Budget three to five weeks for the security risk assessment, access model and logging work. Teams that discover this in week fourteen ship late.

Should you build custom or configure what you already own?

Configure and stop reading if you run one to three locations on one EMR with one path lab and a cosmetic line under roughly a fifth of revenue. ModMed EMA is a genuinely good product for that practice. The body map is fine, the path module works when one clinical lead can hold the whole biopsy pile in their head, and the monthly cost is far below anything you would build. If that describes you and you are frustrated, the problem is workflow discipline rather than software, and we tell people that on calls without charging for it.

Nextech deserves a specific mention if cosmetic is a large part of your revenue, because its cosmetic handling is stronger than the alternatives. Its limits appear at the location boundary: reporting stops there, and package logic breaks the moment a patient wants to redeem sessions at a different office.

The build case is a layer above the EMR, never a replacement for it. Rebuilding an EMR is a seven figure mistake we have watched groups make. Build when you carry more than one EMR with no realistic consolidation plan, when biopsy tracking depends on a spreadsheet a specific human owns, when somebody spends five or more hours a week hand building a revenue report, or when you are acquiring practices and each arrives with its own stack.

How do hidden costs get into the quote?

In Digital Heroes delivery experience a focused first release runs $60,000 to $130,000 and ships in 12 to 16 weeks, and a full platform with lesion timelines, the cosmetic ledger, triage booking and a group dashboard runs $150,000 to $400,000 phased over 6 to 12 months. What moves you within and beyond those bands is rarely the feature list.

• EMR instance count. One tenant is straightforward. Two products plus a legacy instance from an acquisition is three integrations and three data models, and roughly double the integration work.
• Path lab count and format. Every lab sending scanned documents rather than structured results is separate handling and separate testing.
• Patient identity resolution. Matching the same person across your EMR and your cosmetic system on name, date of birth, phone and email, with a human review queue for fuzzy matches, is the foundation everything else needs and is always underestimated.
• Cosmetic package logic. Prepaid session counts are cheap. Memberships, tiered pricing, per injector commission, gift cards and cross location redemption is a small product on its own.
• Image volume and retention, which is a storage and access control cost that recurs rather than a one off build cost.

What separates a dermatology build that works from one that fails here?

The single structural decision is whether the lesion exists as an entity. Encounter centric data models exist because billing is encounter centric, so in every off the shelf product the mole on a patient's left scapula has no stable identifier, and photos, measurements, biopsies and diagnoses have nothing to attach to across four years and three providers. A build that creates the lesion as a first class object with a body map coordinate and a timeline lets a provider compare 2022 against 2026 in four seconds on a patient with thirty tracked lesions. A build that attaches photos to visits has recreated the problem with better styling.

The second decision is where the money is measured. Until patient identity is resolved across your medical and cosmetic systems, you cannot answer what a skin check patient is worth over twelve months, which injector retains best, or how much unredeemed package liability sits on your books. That last number sets your price in an acquisition, so it is worth having before somebody asks for it.

Finally, get code ownership in writing before the statement of work, including the mapping rules between your EMRs and the new schema. That mapping carries more institutional knowledge than any other artefact in the project and hurts most to lose. At Digital Heroes the client owns the repository and the infrastructure accounts from the first commit, and a developer who is vague about ownership has already given you the answer.