EHR interoperability for U.S. telemedicine: integration patterns and constraints

I didn’t start out chasing standards and trust frameworks—I just wanted my virtual visits to feel as seamless as a clinic room handoff. Then the frictions kept piling up: medication lists that didn’t match, labs missing context, consents that lived in three different places. One morning, while sketching flows on a coffee-stained notepad, I realized the heart of it: telemedicine only works at scale when our EHR connections are both clinically meaningful and policy-aware. From that day, I began collecting integration patterns that survive the messy realities of U.S. care and the constraints—technical, legal, and organizational—that shape them.

The moment it clicked during a real video visit

There was a video call with a patient who’d been seen in two health systems the same week. I could pull a continuity document, but not the discrete blood pressure trend the cardiologist relied on. What finally clicked? Interoperability isn’t a single pipe—it’s a set of scoped exchanges tailored to the clinical moment: an authorization flow during scheduling, a read from a primary EHR at check-in, a write-back after orders, and a broader network query when history is scattered. When I reframed the problem this way, each friction point had a home and a fix.

• High-value takeaway: map the telemedicine journey (pre-visit, intake, encounter, after-visit) to the minimum necessary data flows and privilege sets. It cuts risk and reduces implementation bloat.
• Start with standard rails. For app-to-EHR, lean on SMART on FHIR (OAuth-based) for predictable auth and scopes; for network-to-network, check if TEFCA connections are available in your market and use them for patient discovery and document exchange SMART on FHIR TEFCA.
• Expect gaps. Some items still travel best as documents (e.g., external procedure notes), while vitals, meds, allergies, and problems do better as discrete FHIR resources when available.

Where the data actually moves in a telemedicine day

I started sketching four swimlanes—patient, telehealth platform, EHR(s), and exchange network—and everything got easier to reason about.

• Identity & context: patient match, encounter, location, and payer context at scheduling and check-in.
• Clinical read: meds, allergies, problems, vitals, and recent labs pulled just-in-time to avoid stale data.
• Orders & documentation: eRx, labs/imaging, and notes flow back to the system of record with provenance.
• Network queries: when the record is fragmented, query a trusted network for prior documents and results.

Those lanes translate neatly to standards and governance: SMART on FHIR for app launch and API reads/writes, and a TEFCA-connected network (via a QHIN through your EHR or HIE) for nationwide discovery and document exchange. If you anchor on those two capabilities, the rest becomes a set of patterns you can pick from.

Integration patterns that survived contact with reality

These are the ones I’ve used (or wished I had) when time and budgets were tight.

• SMART-embedded visit tools — Launch a telemedicine app inside the EHR with the user in context. Use user-level SMART scopes for what the clinician sees during the encounter, and document via FHIR DocumentReference or Composition. This keeps auditing and authorization clean SMART scopes & launch.
• Standalone SMART with patient-portal handoff — For direct-to-consumer telehealth, authenticate patients in your platform, then hand off to the EHR using patient-level SMART scopes to read meds/allergies or share vitals from devices. It’s great for read-mostly use cases where write-back is minimal.
• Backend service pattern for orchestration — A non-user service account (system-to-system) pulls schedule, caches minimal context, and coordinates FHIR reads ahead of the visit. After the visit, it posts discrete results and a signed note. This is your “glue” when performance matters and clinicians shouldn’t wait on network round-trips.
• Network-first for history, API-first for the now — Use your TEFCA-connected network to retrieve external summaries and results prior to the visit, then use FHIR APIs against the primary EHR for real-time vitals, meds, and orders during the encounter. It keeps latency predictable while still widening the clinical lens TEFCA overview.
• Fallback document gateway — When APIs aren’t available, ingest C-CDA through your HIE gateway or Direct secure messaging into a review bucket, with human-in-the-loop reconciliation for meds/allergies. It’s not glamorous, but it’s better than no history.
• eRx with guardrails — For controlled substances, route through certified e-prescribing workflows and honor electronic controlled substance rules (multi-factor signing, end-to-end integrity). Keep the video platform out of that signing flow to reduce risk DEA EPCS.

The constraints that quietly decide what’s possible

I used to think “constraints” meant just bandwidth and budgets. It turns out the decisive ones are policy and trust:

• Data scope — If you align your payloads to the U.S. Core Data for Interoperability (USCDI), you set a floor for “what must travel” across systems. Newer versions add classes (e.g., device, goals, social determinants) that change what a telemedicine app can safely assume is available USCDI v5.
• Network trust — Exchanging data across organizations at national scale depends on shared legal/technical guardrails. TEFCA creates that backbone via QHINs; if your EHR or HIE plugs in, you inherit standardized exchange terms and security expectations TEFCA basics.
• Granular privacy — Substance use disorder records protected by 42 CFR Part 2 require special handling and consent. In practice, that means segmenting or withholding certain data, or using FHIR Consent with clear purpose-of-use flags, so you don’t overshare by default 42 CFR Part 2 (Final Rule).
• Security by design — The HIPAA Security Rule isn’t optional; it’s the table stakes for telemedicine. Risk analysis, encryption, access management, audit logging, and incident response plans aren’t “nice to haves.” Build them in from sprint one HIPAA Security Rule.

When I accept these constraints early, designs get cleaner. When I ignore them, everything gets harder later—usually right before go-live.

My short list of FHIR resources that matter most on a video call

I keep a sticky note on my monitor: Patient, Encounter, Practitioner, Condition, AllergyIntolerance, MedicationStatement/Request, Observation, CarePlan, DocumentReference. If I can read the first eight and write back a note (or a signed PDF) as a DocumentReference with provenance, the visit usually feels complete. The rest (imaging orders, referrals, care team) are add-ons when the specialty demands it.

• Do first: allergies and meds (safety), recent vitals and labs (context), current problems (framing).
• Do next: orders and documentation with clear authorship/time.
• Do when ready: device data and care plans for longitudinal programs.

Security and privacy guardrails I won’t ship without

There’s a checklist I revisit before any integration moves from staging to prod:

• Least-privilege scopes — In SMART, request the narrowest scopes that allow the task, and expire tokens aggressively. Rotate client secrets and use PKCE for public clients.
• Defense in depth — TLS everywhere, at rest encryption for clinical stores, masked logs, and separate audit/event pipelines so clinical data never sits in analytics logs.
• Segmentation and consent — Honor patient directives for sensitive data classes and reinforce consent UX. Avoid “all data” fallbacks when Part 2 or state law triggers apply OCR telehealth guidance.
• Provenance — Attach who/what/when to every write-back. Downstream clinicians need to trust the source and the time window.

Reliability rules that keep clinicians from waiting

Latency sinks adoption. Here’s what helped me keep visits snappy:

• Pre-fetch essentials (meds, allergies, recent labs) during check-in via backend service accounts; refresh within the visit only when the time window is stale.
• Parallelize network calls and cache immutable resources (e.g., practitioner directory) for hours, not minutes.
• Have a document mode fallback with visual cues so clinicians can continue when APIs hiccup.

How TEFCA and USCDI change the calculus for telehealth

Two shifts stood out to me in the last couple of years. First, TEFCA lowers the overhead of connecting to outside organizations. Instead of bespoke agreements and one-off trust frameworks, you ride a QHIN connection with standardized policies and exchange purposes. That reliability is invaluable when your patient has history in three states. Second, USCDI’s steady expansion raises the baseline for what you can expect in an external record—social needs, goals, and device data are showing up more often, which makes remote care plans more grounded USCDI v5 TEFCA.

Vendor lock-in, interfaces, and the price of “just one more feed”

I’ve paid the “interface fee” more times than I want to admit. A few lessons:

• Push for standards — Every custom CSV or SOAP service is technical debt. Favor FHIR R4/R4B endpoints and published SMART profiles for longevity.
• Inventory interfaces — Keep a living map of every interface with who owns it, data classes, SLAs, and break-glass contacts. When a visit fails, it’s rarely the API; it’s usually the routing or identity layer.
• Plan the exit — If a vendor relationship changes, how fast can you revoke access and pull audit logs? Telemedicine lives on trust, and trust needs clean break points.

Consent is a workflow, not a checkbox

I used to treat consent like paperwork; now I treat it like an operating principle. Decide, at design time, how you will:

• Explain data uses to patients in plain language during onboarding.
• Store consent state and link it to purpose-of-use in your access control rules.
• Segment sensitive data (e.g., SUD, certain reproductive health information) and prefer “opt-in” visibility for cross-org sharing where law or policy is strict 42 CFR Part 2.

What I learned to keep and what I’m letting go

What I keep: a bias for standard rails (SMART on FHIR + TEFCA), a respect for granular privacy, and a focus on journey-mapped data flows. What I’m letting go: over-collecting “just in case,” bespoke interfaces that age poorly, and the idea that interoperability is a one-time project. It’s a practice.

FAQ

1) Does TEFCA replace my FHIR APIs?
Answer: No. TEFCA governs trusted network exchange (great for discovery and documents). FHIR APIs (often via SMART) power app-level reads/writes inside an EHR. Many programs benefit from both for different moments of care TEFCA SMART.

2) What data can I reasonably expect to get for a virtual visit?
Answer: Start with USCDI elements—demographics, meds, allergies, problems, vitals, labs—as your floor. Beyond that depends on your partners’ implementations and specialty needs USCDI v5.

3) How do I handle controlled substance e-prescribing during telemedicine?
Answer: Use certified eRx workflows that meet DEA’s Electronic Prescriptions for Controlled Substances (EPCS) requirements, including identity proofing and multi-factor signing. Keep tight separation of duties and audit trails DEA EPCS.

4) What about privacy for sensitive history in a cross-state telehealth program?
Answer: Combine HIPAA Security Rule safeguards with data segmentation and consent for categories like SUD records protected under 42 CFR Part 2. Implement “need-to-know” access and clear purpose-of-use tagging HIPAA Security Rule 42 CFR Part 2.

5) Is it worth the effort to align to standards now if not all partners are ready?
Answer: Yes. Standardizing your side (SMART scopes, FHIR resource shapes, USCDI mapping, TEFCA participation) lowers your long-term cost and makes each new connection faster. Use transitional gateways (e.g., document exchange) while partners catch up.

Sources & References

• ONC — TEFCA
• ONC — USCDI v5 (2024)
• HL7 — SMART App Launch
• HHS OCR — HIPAA Security Rule
• Federal Register — 42 CFR Part 2 Final Rule

This blog is a personal journal and for general information only. It is not a substitute for professional medical advice, diagnosis, or treatment, and it does not create a doctor–patient relationship. Always seek the advice of a licensed clinician for questions about your health. If you may be experiencing an emergency, call your local emergency number immediately (e.g., 911 [US], 119).