Dermatology Platform System Design

Platform System Design in a Dermatology Practice

Skin practices grow in uneven ways. A group adds a satellite clinic, hires a Mohs surgeon, opens a cosmetic suite or takes on a dermpath lab. Unlimited Systems runs as one cloud platform, so a new site or provider is added to the same data model instead of a separate install. Users sign in through roles that the practice sets, so a front desk member does not see the same screens as a coder or an owner. Medical, surgical, pathology and cosmetic revenue share one patient record and one ledger, but each can be reported on its own. Partners that handle patient data sign a business associate agreement, and the practice's own policies cover how staff use the system. Changes to codes, payer rules and user access leave a record that can be reviewed later.

Why Is Platform System Design Different in Dermatology?

A skin practice mixes several kinds of business in one name. Medical visits go to payers. Surgical and Mohs work depends on global periods and unit counts. A dermpath lab brings its own components and certification. Cosmetic care is a self-pay line of business. A platform built for only one of these has to be patched for the rest. Platform system design for dermatology starts from the idea that all four live side by side.

Platform system design also has to cope with growth, which often comes by acquisition or by adding sites. New clinics bring their own schedules, fee lists and payer mixes, and often their own old software. A cloud platform with one data model lets a new site start with its own settings and still roll up into the group's reports. Moving a site in becomes a setup task, not a new system, and the group does not hold different versions of the truth.

Security also looks different here than in many specialties. Dermatology records can include photographs and sensitive diagnoses, and a front desk, a cosmetic coordinator and a surgeon do not need the same view. Card payments for cosmetic work, including any card on file, add a second rule set to follow. Clear roles, logged changes and a clean split between clinical, financial and card data make the platform easier to defend in an audit and easier for staff to use.

What Dermatology Platform System Design Handles

Role-based access

Roles control what each user sees, such as claims, patient balances, cosmetic prices or reports. Access is set by the practice and reviewed when staff change jobs. HIPAA requires that workers see only the information they need for their duties. (HHS Office for Civil Rights: Guidance on De-identification of Protected Health Information under the HIPAA Privacy Rule)

Card data handling

Cosmetic and copay payments by card fall under the PCI Data Security Standard. The platform design keeps card handling separate from the rest of the patient record, so the practice's own exposure to card data stays small. (PCI Security Standards Council: PCI Data Security Standard)

Standard transactions at the core

HIPAA adopts X12 formats for claims, eligibility, claim status and remittance. The platform uses these standards for every payer, so adding a payer is a setup task, not a new build. (CMS: Adopted Standards and Operating Rules (HIPAA transactions))

One data model for Mohs, surgery and lab

Mohs stage units, excision and repair lines and pathology components all sit in one charge structure. For Medicare in WPS states, added stages are units of 17312 or 17314, and the same charge model carries those units. (CMS Medicare Coverage Database, Billing and Coding Article A57477: Mohs Micrographic Surgery (WPS))

Rules that live in data

Payer edits such as the NCCI pairing of a biopsy with an excision of the same lesion are held as rules the practice can change. When a manual or LCD changes, billing leads update the rule instead of waiting for a code release. (CMS NCCI Policy Manual for Medicare Services, Chapter III (Surgery: Integumentary System))

Filing deadlines held on the claim

Each claim keeps its date of service and its status, so timely filing limits such as the one-year Medicare limit in 42 CFR 424.44 can be watched across every site at once. (eCFR: 42 CFR 424.44, Time limits for filing Medicare claims)

How Does Dermatology Platform System Design Work?

1. 1. Model the organization

   Platform system design begins with the org chart. The practice sets up its sites, providers, specialties and service lines, such as medical, Mohs, pathology and cosmetic. Each gets its own fee list and payer rules where needed.

2. 2. Set roles and access

   Leads assign roles to each user. A coder, a poster, a front desk member and an owner see different screens. The assignments are reviewed when someone changes jobs or leaves.

3. 3. Connect the surrounding systems

   The platform is connected to the chart, labs, payers and the bank using the standards in dermatology EHR integration. Each connection is tested before go-live.

4. 4. Add sites and providers

   A new clinic or surgeon is added to the same platform. It inherits the group's rules and reports, and can carry its own settings.

5. 5. Review and audit

   Changes to rules, codes and user access are logged. Managers can look back to see who changed what and when, which supports internal reviews and outside audits.

Dermatology Platform System Design vs. Generic Software

Who Uses It in a Dermatology Practice

• Practice owner: Platform system design that gives one platform for every clinic and service line, with a way to add sites that does not mean a new system. Group results roll up from the same data.
• IT or compliance lead: Platform system design with clear roles, logged changes and a business associate agreement with the vendor, so reviews and audits rest on records, not memory.
• Billing director: Payer rules and standard transactions that can be changed in setup, and one place to watch every site's timely filing exposure.