Home / Compare / Custom-built app
PlatinumMED's custom app vs DMEDesk
PlatinumMED, a Las Vegas DME shop, runs its own in-house app and is DMEDesk's design partner. This page compares the two honestly, based on PlatinumMED's source code as of its latest commit on October 29, 2026. Today the custom app does much more.
Internal review · Not indexed · Nov 2026DMEDesk status: DMEDesk is a design concept with an undeployed first build. Tenant isolation is not yet proven, there is no billing/Stripe, no HIPAA Business Associate Agreement yet, and QuickBooks support is CSV export only.
The short version
Custom app is ahead on
- Delivery scheduling and the driver portal
- Barcode labels and scanning
- E-sign forms and document center
- Hospice contracts with bundles and caps
- Patient and organization portals
- Compliance checklist and the DME Bot draft
DMEDesk is designed for
- Many shops, each isolated (not yet proven)
- Self-serve company sign-up
- Template CSV import with dry run
- A vendor-maintained product instead of one in-house codebase
- A published proposed price
Both cover
- Patients, orders and organizations
- Serialized rentals and supplies
- Signed proof of delivery
- Cleaning and maintenance gates
- Hospice invoicing (much deeper in the custom app)
Feature by feature
| Area | PlatinumMED custom app | DMEDesk |
|---|---|---|
| Built for | One company (PlatinumMED). Tables have no tenant/company column; access is admin vs employee. | Many shops. Per-company sign-up and row-level tenant isolation designed; isolation not yet proven in testing. |
| Status | Running app (React + Vite on Vercel, Supabase Postgres + Auth). 58 database migrations, 7 Playwright test files. | Static design concept plus an undeployed first build on Neon. |
| Patients | Profiles with medical fields, ICD-10 diagnosis picker, practitioner NPI lookup, history, and statuses (active, inactive, on hold, discharged, deceased) that pause billing and block new orders. | Patients and orders with source documents. No ICD-10 picker, NPI lookup or status-driven billing pause yet. |
| Orders | Mixed rental + supply orders, line pricing, admin price and total adjustments, order numbers, SWO / diagnosis compliance checklist. | Orders with supply lines and serialized rentals. No compliance checklist yet. |
| Rental equipment | Serialized units with lifecycle history, storage locations, barcode labels and camera scanning. | Serialized units with status. No barcode labels or scanning yet. |
| Supplies | Supply catalog imported from a spreadsheet, categories (incontinence, wound care, urology, PPE, personal care), supply invoices. | Supply bins tracked by quantity; supply sales on orders. |
| Deliveries | Schedule with delivery, pickup, exchange/swap and maintenance-pickup stops; driver portal with en route / completed / failed; signed POD PDF. | One driver-stop view with a signed-POD gate (concept). No scheduling board or route view. |
| Maintenance | Intake → cleaning → inspection → repair → ready, with configurable clean / inspect / test step templates. | Hold → service → release gate (concept). |
| Hospice billing | Per-organization contracts: per-patient-day or per-patient-month bundles, caps, emergency fee, sales tax switches; rental, supply and combined invoice PDFs. | Per-diem invoice review (concept). No contract bundles, caps or PDF invoices yet. |
| Portals | Organization portal and patient self-serve portal (pickups, documents, invoices, catalog requests, activity). | Facility portal concept only. No patient portal. |
| Documents and e-sign | Document center with folders and access scoping; e-sign templates (delivery ticket, rental agreement, assignment of benefits, ABN). | Source documents on orders. No e-sign. |
| AI | DME Bot: intake review, paperwork check and resupply queue. Its rule sets are marked as drafts pending clinical review. | None in Core. A future intake assistant is a separate readiness gate. |
| Import / export | Patient CSV import, catalog spreadsheet import, export menu. | Versioned CSV import/upsert with dry run; CSV export (including for QuickBooks). |
| Billing to the shop | None. It is the shop's own software. | Proposed $499/month Core; no Stripe connected, no live charges. |
| Compliance posture | Depends on PlatinumMED's own vendor agreements; not assessed here. | No HIPAA Business Associate Agreement yet. Real patient data waits for one. |
What migrating PlatinumMED would take
- Reach feature parity first. Scheduling, scanning, e-sign, portals, contract bundles and caps, and the compliance checklist would need to exist in DMEDesk. Otherwise moving would be a step backwards.
- Prove tenant isolation. Two-shop isolation tests with fictional shops must pass before any second shop shares the database.
- Sign a BAA. No real patient record moves until a HIPAA Business Associate Agreement covers hosting.
- Map the schema. Patients, organizations, items, inventory units, orders and order lines, delivery stops, maintenance queue, invoices, contracts and documents map to DMEDesk tables. Source IDs would be kept for reconciliation.
- Move files. Uploaded documents and signed PODs live in Supabase storage and need a storage target in DMEDesk.
- Run both in parallel. Dry-run imports, then a cutover after a delivery, a pickup and an invoice reconcile in both systems.
Recommendation: keep PlatinumMED on its custom app for now. Use it as the reference for what DMEDesk must do, and port proven workflows into DMEDesk one at a time.
How this was reviewed
Read-only review of the PlatinumMED repository: README, sidebar navigation, types, migrations, edge-function names and feature folders. Nothing was pushed, branched or changed, and the production database was not touched. No patient, hospice or staff names from the repository are reproduced here. The PlatinumMED example workspace uses only fictional records.
See the workflow before you decide.
Explore the fictional Acme workspace or the PlatinumMED example. Nothing is stored or sent.