| This article is part of our series on Custom Dermatology Practice Platform Development for US Dermatology Groups: Building a Dermoscopy Imaging, Pathology and Cosmetic Billing System |
An Architecture, an Interface, a Workflow and a Ledger
Planning image capture, a pathology interface, store-and-forward review and billing separation as a single integration workstream distorts both scope and cost, because each is a different kind of engineering problem. Image capture is primarily an architecture decision. It determines how photographs attach to anatomy, how the archive is stored as volume grows and how images are retrieved later for comparison. Get that wrong and the result is a folder of pictures rather than a clinical record. The pathology interface is a genuine data exchange, but it carries an unusual requirement at the receiving end, which must never let a result disappear. Store-and-forward teledermatology is mostly a workflow problem, since image quality from a patient’s own device causes more friction than any data transfer does. Split billing is a ledger design question, and the interesting part of that design is what the system must refuse to do.
Reaching this stage usually follows a decision to commission custom software development built specifically around dermatology workflows, paired with web application development covering the patient portal, cosmetic booking and store-and-forward submission, all public-facing surfaces with accessibility obligations attached.
This article works through image capture, the pathology interface, store-and-forward review and split billing in turn, along with the supporting connections and the reconciliation discipline the chain depends on. Nothing described here analyzes an image to reach a clinical conclusion, since that function is a regulated medical device.
Dermoscopy and Clinical Image Capture
Capture Devices and the Practical Reality
Dermatoscopes attach to phones, exist as dedicated cameras or stand alone as fixed units, and most practices end up using a mix of all three. Total body photography systems are separate equipment again. The integration question is getting images off each device and into the record, associated correctly with the right patient and the right lesion. The practical failure mode is an image captured on a personal phone that never reaches the record at all, which is both a clinical gap and a privacy problem.
Association Is the Architecture
An image is only useful if the system knows what it shows. That requires a structured body map with persistent lesion identifiers, association happening at the point of capture rather than afterward, and enough metadata such as date, device, view and magnification for a later comparison to be meaningful. Free-text location notes are the failure mode here, since retrofitting association onto an archive of unassociated images is close to impossible. This makes body-site mapping the decision to get right in the first release rather than a refinement to add later.
Storage at Volume
A busy practice generates images at a rate that makes storage architecture a real consideration on its own. Tiering between recent and archival storage, retrieval speed for side-by-side comparison, retention obligations and the cost curve as the archive grows year over year all need modeling before a storage approach is chosen, because the volume only moves in one direction. Imaging at volume and the pathology interface also influence the overall estimate, as outlined in Cost to Build a Custom Dermatology Practice Platform for a US Dermatology Group: Full Budget Breakdown.
Pathology Lab Result Interfaces
The exchange itself is well established. Laboratories transmit results using standard healthcare messaging formats, and receiving them into a record is ordinary integration work that outside laboratories and in-house laboratory systems both support. What deserves engineering attention is the receiving end, because this is where the specialty’s most serious and best documented failure occurs. A result arriving in a system is not the same as a result acted upon.
The design requirements follow from that distinction. Results route to the ordering provider and require explicit acknowledgment before they can be considered filed, with nothing filed automatically. Abnormal or malignant findings surface distinctly rather than sitting in a general queue. Provider absence triggers coverage rather than leaving a result waiting in an inbox nobody opens. Patient notification is then recorded as an event rather than assumed, capturing who was contacted, when, by what means and whether contact succeeded. Failed contact escalates on a defined schedule instead of quietly expiring, and required follow-up is tracked through to completion, since a scheduled excision the patient never attended has not closed the loop.
Practically, this means specimen identifiers matched correctly on return, results matched to the correct body site, and an open-loop report the practice actively reviews rather than a filing cabinet it trusts. Turnaround monitoring rounds this out, flagging a specimen that never produced a result before it is forgotten.
Store-and-Forward Teledermatology
The technical exchange behind store-and-forward is trivial. The real problem is that a patient holding a phone is not a photographer, and an unreviewable submission wastes both the patient’s time and the reviewing provider’s. The capture experience has to carry most of the workload, offering guidance on framing and distance, lighting prompts, a scale reference where size matters, multiple angles requested explicitly and immediate feedback when an image is obviously too dark or out of focus. Structured history should accompany the photograph, since an image without duration, symptoms and change over time is not a consultation.
The review workflow needs an explicit path for requesting better images or additional views rather than pushing the reviewer toward a conclusion on inadequate material. It also needs a path for concluding that the presentation requires an in-person visit, which is frequently the right outcome. Once reviewed, the response becomes a documented encounter held to the same standards as any other. Referring-provider submissions, where a practice accepts cases from primary care, work the same way with the referring clinician as the submitter.
Point-of-care image capture on a clinical device and guided patient submission for store-and-forward review are core use cases for custom mobile app development, since capture quality has such a direct effect on review outcomes. The regulatory layer sits underneath all of this. Licensure generally follows the patient’s location, consent requirements and prescribing limits vary by state, and reimbursement for asynchronous review differs by payer and by state. These need verification per state before the service is designed, not after. The workflow these connections power, and where each capability sits in a practice’s build order, is covered in Dermatology Software Features: Feature Priorities for a US Medical, Surgical and Cosmetic Dermatology Practice.
Split Medical Versus Cosmetic Billing
This is a ledger design problem, and the decisions that matter most here are about restraint rather than mechanics. On the mechanical side, two financial paths run out of one encounter. Medical and surgical services flow to claims, with eligibility checks, authorization, remittance posting and denial handling attached. Cosmetic services flow to a retail path instead, with posted prices, payment at time of service, packages with sessions drawn down, memberships and product sales.
A patient account needs to present both paths clearly, since a patient who assumed a procedure was covered and later finds it billed to them privately produces one of the most common complaints in this specialty. A quoted price given before treatment, alongside an account that shows the split plainly, is what prevents that outcome. Package and membership structures raise their own regulatory questions and should follow a structure counsel has reviewed and approved in advance.
What the ledger must never do is the design decision that matters most. It cannot determine or influence whether a service was medical or cosmetic. The provider records a clinical indication, and the system simply carries that record forward. There is no default characterization, no prompt suggesting one path over the other, and no reporting that presents a medical-billing rate as a measure of provider performance. Billing a payer for care that was cosmetic is a false claim, and software that leans on the determination in either direction is participating in producing one.
Supporting Connections
A clearinghouse handles claims, eligibility and remittance on the medical side. Payment processing covers time-of-service collection, portal payments, package purchases and recurring memberships. Prior authorization services or payer portals matter because biologic authorization is a substantial workload on its own, and prescribing connections need the monitoring some therapies require. Laboratory systems come into play where in-house pathology runs its own, and inventory or supplier connections handle injectables, devices and dispensed products with lot tracking. Quality reporting submission runs through whichever pathway the practice uses, and messaging supports recall, appointment reminders and result notification through consented channels. Accounting sits at the end, with service line separation preserved throughout. Each of these connections carries its own onboarding, and where protected health information is involved, a business associate agreement should be confirmed before any design work assumes its terms.
Reconciliation and Failure Handling
One failure category here is a patient safety matter, and the rest are commercial. A specimen with no returned result can represent a patient whose diagnosis has not reached the practice, making this the highest-priority exception to detect. The remaining gaps are operational: an image captured but never associated with a lesion, a claim submitted without acknowledgment, a package session drawn down without a matching service, or a store-and-forward submission left unreviewed. Each needs a queue with a visible age and a named owner. A daily reconciliation should compare specimens sent with results received and resolved, while broader exception review checks aging tasks across imaging, billing and teledermatology. Each integration therefore needs a defined failure state, visible ownership and a reconciliation point before the workflow is considered complete.
Final Thoughts
A dermatology platform becomes dependable when its integrations preserve the clinical context around each transaction. Images need a reliable body-site association, pathology results need an acknowledgment and follow-up path, teledermatology needs a review workflow that can stop when the submission is inadequate, and billing needs to carry the provider’s medical-versus-cosmetic determination without influencing it.
These decisions also shape the build beyond the individual integrations. Image volume affects storage and retrieval architecture, pathology workflows affect notification and reconciliation requirements, and billing separation affects how financial data moves through claims, payments and accounting. Treating each layer as a defined workflow rather than simply connecting another system keeps the platform easier to test, monitor and extend.
For practices moving from disconnected tools to a platform built around these workflows, working with an AI software development company can help translate the clinical, operational and integration requirements into a system architecture that is practical to build and maintain.
