Every telehealth platform that grows past one state hits the same wall. The MVP shipped in one state, the platform worked, you raised. Now you want to expand to five states, and your provider routing — which was a function that returned the same provider regardless of patient state — starts producing illegal visits.
This article is the practical version of what most telehealth platforms eventually need: a multi-state licensing architecture that doesn't depend on heroics or spreadsheets.
State lines are software boundaries
A telehealth visit is regulated at the patient's state of presence — not the provider's state, not the patient's residence, not the company's HQ. If a patient is in Ohio at the moment of the visit, the visit must comply with Ohio's medical practice rules. The provider needs an Ohio license. E-prescribing must follow Ohio's PDMP rules. Scope-of-practice must match Ohio's NP or PA rules. None of this is the same as the patient's billing address.
Every multi-state platform we've shipped routes visits at session-bind time based on patient state of presence — captured explicitly, not inferred from IP or billing.
The three things state licensing actually controls
Who can practice (license verification)
Every state has a board of medicine (and separate boards for nursing, behavioral health, pharmacy, etc). Each board issues licenses with a status and expiration. License status changes — providers move states, take licenses inactive, fail license renewal. A platform that assumed a provider's Ohio license is still valid 18 months after onboarding is a platform that will eventually conduct an unlicensed visit.
License verification is a recurring requirement, not a one-time check.
What they can do (scope-of-practice)
A nurse practitioner in California has independent practice authority. A nurse practitioner in Texas does not — they require physician supervision. Same license type, two states, different scope. Your platform's "who can prescribe what" logic needs to encode this.
How they prescribe (state-level e-prescribing + PDMP)
E-prescribing of controlled substances (EPCS) is federal-required, but state-level PDMP (prescription drug monitoring program) integrations vary widely. Some states require a PDMP check before every Schedule II prescription. Others before every controlled substance. Your e-prescribing flow needs to know which state's PDMP applies and integrate with it.
The routing problem
At visit-bind time — the moment a patient confirms a visit and the system assigns a provider — three pieces of state data converge:
- Patient's state of presence (captured explicitly during intake)
- Eligible providers' state licenses (must include patient's state)
- Provider availability (calendar) intersected with state-eligible providers
The output is a single provider assignment plus an audit log of why. The audit log is critical — if a board ever asks why a Texas patient was matched with a Florida provider, you need to show the licensing match in your routing decision.
License verification — manual or automated
There are state licensing board APIs. Few states publish them officially; most are scraped via partners (Nursys for nursing, AMA for physician verification, and CredentialMyDoc / similar for multi-discipline). Your options:
- Manual verification at onboarding, manual re-verification quarterly. Cheap but error-prone.
- Vendor (Verifiable, CertifyOS, similar) for automated continuous monitoring. Costs ~$15–40 per provider per month but handles status changes.
- Self-built scraping of license boards. Possible but maintenance is expensive — boards change their sites.
For platforms above ~50 providers, vendor-automated monitoring is the right call. The error mode (provider's license lapsed and you didn't catch it) is too costly otherwise.
Compact licenses — IMLC, NLC, PSYPACT
There are three big compacts:
- IMLC (Interstate Medical Licensure Compact) — for physicians. Member states (40+) accept a streamlined application process, not a single license.
- NLC (Nurse Licensure Compact) — for RNs and LPNs. ~40 states have full reciprocity.
- PSYPACT — for psychologists. ~40 states.
Compacts simplify the licensing application process, but they don't simplify your routing logic — providers still hold individual state licenses (just acquired faster). Your routing engine still needs to know which states each provider is licensed in.
Compacts also have gaps. Controlled substance prescribing typically requires state-by-state DEA registration even within a compact. Behavioral health has its own compact (PSYPACT) separate from medical.
What we build for multi-state platforms
Architecture that survives 50-state expansion:
- Provider state matrix — explicit record of which states each provider is licensed in, expiration dates, scope-of-practice tier
- Visit routing engine — at bind time, filters available providers by patient state of presence, then by scope match, then by calendar availability
- License monitoring — continuous (daily delta against state board data, via vendor)
- Audit log — every routing decision logged with state, license version, and timestamp
- Scope-of-practice rules engine — configurable per state, encodes what each license type can do
Common failures
Patient-state vs patient-residence assumption
Patient's billing address is in Ohio. Patient is on vacation in Florida. The visit is regulated by Florida law. Platforms that route by billing state catch this only when there's a complaint. Capture state of presence explicitly during intake — every visit, every time.
Stale license cache
A provider's license expires. Your platform's cache says "valid until 2027" because it was checked once at onboarding. You schedule a visit. The visit happens. The board audits. You owe an explanation. License verification should refresh on at least a daily cadence in production. Monthly is too slow.
Missing scope-of-practice rules
NP in California can prescribe Schedule II independently. NP in Texas needs physician supervision for Schedule II. Same license type, different scope. If your platform doesn't encode this, your routing will produce illegal prescriptions in restrictive states.
The minimum to build before you cross state #2
- Patient state of presence captured at visit start (not just at registration)
- Provider state matrix table (one row per provider × state combo)
- Visit binding logic that filters by state license match
- Audit log of routing decisions
- License expiration monitoring (manual at first, vendor by provider #50)
Everything else (compact handling, scope-of-practice rules, PDMP integration) is build-as-needed when expanding to specific states. But the basics above are non-negotiable on the day you accept your second state.
Multi-state telehealth is solvable. It's not a one-week task. Plan for 4–8 weeks of architecture work the first time you cross state lines — much cheaper than the audit that's coming if you don't.