Telehealth Platform Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the video layer get scoped as an embed so often?

Because the demo is easy. Any competent developer can drop a video component into a page in a day, so the estimate treats it as a component rather than as the visit.

The visit is not a video call. It is a virtual waiting room that checks the camera and microphone before the clinician is involved, a copay collected at the door, the chart surfaced to the clinician before they connect, one permanent patient link that always routes to their next appointment rather than an expiring meeting identifier, and attendance and duration written back to the record when it ends. That last part is what your biller currently reconstructs by hand from a meeting report and a ledger that disagree.

The group visit case breaks naive builds entirely. A therapist running back to back sessions on a personal meeting room has patient B joining while patient A is still speaking, and a browser join flow that defeats a 68 year old patient every Tuesday is a clinical access problem, not a user experience quibble.

The fix is to scope the visit lifecycle, not the video widget, and to use an infrastructure provider under your own business associate agreement rather than building transport yourself. Daily, Twilio Video and Vonage are the credible options, weighed on agreement terms, per minute cost at your session volume and reconnection behaviour on poor rural connections. Anyone proposing to build web real time communication infrastructure from scratch for a clinic your size is spending your money on their education.

What goes wrong when years of practice management records are migrated?

The export exists, which lulls everyone. SimplePractice provides exports covering client records, notes and documents, so migration gets priced as a mapping exercise. The difficulty is in the notes and the attachments.

Progress notes accumulate across template changes, so a note from 2021 has a different structure from one written last month, and flattening them into a single format destroys clinical meaning that a payer audit may later ask about. Attached documents are the other trap: signed consents, insurance cards, referral letters and outside records, often stored with filenames that meant something to whoever uploaded them. Screener results captured as free text inside notes cannot be turned into trended scores retrospectively, so a promise that the new system will chart six months of patient health questionnaire results is usually a promise it cannot keep for historic data.

The fix is to make migration a scored deliverable in the contract with a verification step and a parallel running period, so the front desk never loses access to patient history for a single day. Agree what fidelity means before the work starts: notes preserved as rendered documents with structured metadata is a defensible target, reinterpreting historic clinical text is not. The developer who asks to see your export before quoting is the one who has done this.

Why do clearinghouse, e-prescribing and payment integrations break after launch?

Because each one has a certification or an approval process that runs on somebody else's timetable, and because payer behaviour is not uniform.

• Claims are payer specific in practice. A clearinghouse such as Claim.MD or Availity gives you one interface, but individual payers reject on their own rules, and the edge cases only appear against live claims.
• Eligibility responses vary in quality. A plan that returns active coverage may still deny the service, so a check that reassures the front desk can create false confidence.
• Electronic prescribing carries certification, and controlled substance workflows add identity proofing and two factor requirements that are a project rather than a feature.
• Payments split across models. Card on file for cash pay, subscriptions for memberships and consolidated invoicing for an employer contract are three different flows that a single processor integration does not cover by default.

The fix is to name each integration in the contract with its own acceptance test and its own start date, and to begin certification processes in week one rather than when the feature is ready. Ask a supplier which clearinghouse they have submitted live claims through and what they learned, not whether they can integrate one.

What happens when multi state licensure and consent rules are not covered?

Scheduling quietly becomes a legal function performed by whoever answers the phone. Once clinicians hold licences in different state combinations, the matrix lives in a spreadsheet, and a scheduler books a patient in one state with a clinician licensed only in a neighbouring one. The exposure lands on the owner, and it surfaces either as a denied claim or as something considerably worse.

Consent has the same shape. Documents differ by state and change over time, so a practice operating across four states is either using a lowest common denominator form or relying on staff to pick the right one. Neither survives an audit that asks for the signed consent in force on a specific date.

General purpose schedulers will not solve this, because state licensure is a healthcare problem rather than a calendar problem, and no product sold to a broad market models it as a booking constraint.

The fix is to make licensure a first class part of the data model. Each clinician's licences and expiry dates are recorded, the patient's state at time of visit is confirmed during booking, and an ineligible clinician is simply never offered. Consent documents swap automatically per state and are versioned, every booking decision writes to an audit log, and renewals trigger alerts 90 days out rather than being discovered when a claim is denied.

Should you build custom or configure what you already own?

Plenty of practices should stay exactly where they are. If you run standard one to one visits billed per session, you are under roughly 8 clinicians, and your real complaint is subscription cost, stay on SimplePractice. Around $49 to $99 a month per clinician is dramatically cheaper than owning software, and a custom platform you do not operationally need is an expensive hobby. Solo practitioners and small groups with conventional care models should not build.

Configure harder before you commission. Use the practice management system's own telehealth rather than pasting Zoom links, since the copy and paste chain is the source of most missed visits. Use its form templates for intake even though responses stay as documents. Tighten your reminder settings. Those changes cost nothing and remove a meaningful share of the pain.

Build when you are paying humans to be middleware, meaning a coordinator whose job is copying data between systems. Build when you are refusing revenue because the software cannot bill your model, which is the case for memberships, intensive outpatient programmes, sliding scale tiers and employer contracts where one company is invoiced for many patients. Build when multi state licensure is enforced by memory. And if you are a funded virtual care business, the platform is the product rather than overhead, and you should be off rented portals before your first 500 patients.

How do hidden costs get into the quote?

Through compliance and through per state variation.

• States counted as one. Each state whose rules you encode brings its own consent forms, its own licensure handling and sometimes its own documentation expectations.
• Electronic prescribing, where partner certification and controlled substance workflows drive both cost and calendar.
• Native mobile apps instead of a mobile web experience, which doubles the surface and adds store review cycles.
• Migration depth, since years of notes and attached documents take real engineering rather than a mapping script.
• Usage based running costs. Video minutes and messaging fees scale with session volume, and they are ongoing rather than build cost.
• Maintenance. Budget roughly 15 to 20 percent of build cost per year for hosting, security patching, dependency updates and a modest stream of improvements. This is real money and it is exactly why practices without an operational need should keep renting.

Ask for the estimate broken down per state, per integration and per platform, and ask what the first year of running costs looks like.

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

Compliance designed in from the first sprint rather than added before launch. Encryption of patient data at rest and in transit, role based access control, complete audit logs of who viewed which record, automatic session timeouts, and protected health information kept out of error trackers and server logs. Every vendor touching patient data, including the video provider, the messaging service and the hosting layer, signs a business associate agreement. None of that adds a phase when it is built in, and all of it is expensive to retrofit.

The second marker is whether intake is data or paper wearing a digital costume. A fillable form emailed to a patient, printed by half of them, photographed and retyped by an admin is the largest source of transcription error in virtual clinics, and screener scores buried as free text inside notes cannot be trended. Structured intake with conditional logic, computed screener scores that plot in the chart, versioned e signed consents and insurance card capture in the same flow removes the retyping entirely.

When vetting a developer, open with where protected health information can leak in their standard stack. A team that has shipped healthcare software immediately talks about scrubbing patient data from error trackers and server logs and about agreements with every subprocessor. A blank look there ends the meeting. Then ask which video infrastructure they would choose and why, and demand a billing story with named parts.

Finally, confirm in writing that you own the code outright, in a repository you control, with infrastructure accounts in your company's name and full assignment on payment. At Digital Heroes clients own the complete codebase and all deployment credentials from day one. Avoid any arrangement where the agency hosts on accounts they own.