Open APIs and FHIR in telehealth: integration impact on platform selection

Last week I sketched two columns on a notepad—“features I love” and “friction I keep repeating.” The surprise was how often those frictions were integration chores: matching patient IDs, wiring up authorization, translating lab codes, chasing down undocumented endpoints. I realized my best telehealth decisions lately weren’t about shiny workflows at all; they were about how “open” a platform truly was. Not open as a slogan, but open as in predictable APIs, solid FHIR support, and clean ways to plug into EHRs and payers without a maze of one-off contracts. That realization shaped how I now choose telehealth platforms, and I want to share both the feelings (the little wins and headaches) and the practical notes that have saved me time.

When “open” actually saved me weeks

For a long time, “open API” felt like sticker text. Then I worked on a rollout where the vendor’s FHIR server passed a basic smoke test on day one, and I watched our build timeline shrink. An open, documented, standards-aligned API meant fewer translation layers and far less back-and-forth. If a platform supports FHIR (the Fast Healthcare Interoperability Resources standard), exposes a SMART on FHIR launch flow, and mirrors US Core profiles, the integration curve is calmer. If those words sound new, a quick primer helps: HL7’s own overview of FHIR is a gentle starting point (FHIR overview), and the SMART App Launch spec explains how apps securely connect using OAuth 2.0 (SMART App Launch).

• High-value takeaway: ask vendors to demo a SMART on FHIR launch against a sample patient, live. Seeing OAuth scopes, a launch context, and a FHIR read of Patient and AllergyIntolerance beats a slide deck.
• Confirm alignment to US Core profiles or clearly documented profiles. The closer they are to common profiles, the lighter your mapping burden.
• Check how they handle population or bulk data (for quality, risk, or panel management). Even if it’s a future phase, you’ll thank yourself later.

The moments that made FHIR “click” in telehealth visits

I remember the first time a remote BP cuff reading flowed into the visit without a CSV ritual. The magic wasn’t the device—it was the Observation resource arriving with the right LOINC code, units, and timestamps. FHIR doesn’t promise perfect data, but it does give us a common shape. Pair that with an EHR that supports the certified standardized API requirement (ONC’s 170.315(g)(10)) and you’re not reinventing the wheel (ONC API criterion).

• Vitals and trends arrive as Observation with code systems you can validate.
• Medication lists from MedicationStatement/MedicationRequest give enough context to avoid duplicate therapy conversations.
• Allergies (AllergyIntolerance) and problems (Condition) help pre-visit triage feel personal, not generic.

It’s not perfect—telehealth sometimes deals with devices and home data that are noisy. But when data classes align with the United States Core Data for Interoperability (USCDI), you’re negotiating less about “what” and more about “how” (USCDI).

A simple field guide I use before I sign anything

This is the three-step lens I now use to separate “open” from marketing buzz:

• Step 1 — Notice: Is there a public developer portal, versioned API docs, a test sandbox, and example SMART on FHIR launches? Are READY codes human-readable? Is the /.well-known/smart-configuration (or equivalent) discoverable?
• Step 2 — Compare: Do they support FHIR R4/R4B (still the common baseline) and clearly state which resources and profiles they implement? How do they handle Subscriptions (eventing), Bulk Data, and terminologies?
• Step 3 — Confirm: Does the platform’s OAuth approach match the SMART spec (PKCE, refresh tokens, granular scopes)? Are scopes limited and auditable? Is there a written de-provisioning flow and data export plan?

For context, the US regulatory environment encourages these capabilities. ONC’s certification criteria require a standardized API for patient and population services using FHIR, and CMS rules push payers toward FHIR-based APIs for patient access and prior authorization (CMS Interoperability rule).

Scenarios that changed how I rank platforms

I’ve tried three patterns in the last year, each leaving a strong impression:

• Embedded clinician apps inside the EHR: The right platform let us launch a SMART app with context (patient, encounter) so a telehealth room could pre-load meds, labs, and allergies without extra clicks. The wrong platform made us maintain brittle SSO plus custom context APIs.
• Standalone clinician portal with EHR integration: FHIR reads were easy, writes (e.g., notes or orders) required careful privilege design. Without clear scopes, everything got “all or nothing.” The better vendors had role-based, least-privilege bundles.
• Patient-facing mobile apps: We leaned on the patient access API model. Consent screens mattered. Platforms that handled token lifetimes, key rotation, and revocation cleanly kept us out of midnight triage mode.

Data that actually helps a video visit feel complete

Not all data is equal during a 20-minute call. I prioritize the following FHIR reads first:

• AllergyIntolerance and MedicationRequest/Statement to reduce medication mishaps.
• Observation (vitals, home readings) to anchor the narrative in objective signals.
• Condition (active problems) and CarePlan (goals, activities) to keep continuity across in-person and virtual settings.
• Appointment and Encounter for scheduling sanity and documentation trails.

Platforms that surface these via consistent US Core profiles make pre-visit triage smoother and post-visit documentation more defensible. If you want to sanity-check what “standardized API” means in certification language, ONC’s page is very readable (ONC API criterion).

Security that feels like a seatbelt, not a brick wall

My happier integrations used SMART on FHIR with OAuth 2.0 and PKCE. That meant short-lived access tokens, refresh tokens with rotation, and scopes that made sense to a human (“read allergies,” not “superuser”). I also look for:

• Clear scope catalogs and environment parity (dev, test, prod) so security testing isn’t guesswork. See the spec for what good looks like (SMART App Launch).
• Auditing and patient transparency: API calls should be logged with purpose and subject, so you can answer “who saw what and why.”
• De-identification options for analytics sandboxes and research-like quality improvement, keeping PHI out of places it doesn’t belong.

Regulatory currents that shape real roadmaps

Even if you’re not a payer, CMS’s Interoperability and Prior Authorization Final Rule pulls the ecosystem toward FHIR APIs for patient and provider access and prior auth status exchange. I’ve seen vendors accelerate their roadmaps because of it (CMS rule overview). On the provider side, ONC’s certification criteria keep pushing for standardized, patient-facing and population APIs, which protects your investment in standards (ONC API criterion). Pair that with USCDI’s evolving data classes and you get a clearer expectation of what “minimum useful data” should flow (USCDI).

How I score “integration-readiness” in a demo

• FHIR version and profile transparency: R4/R4B clarity, list of supported resources, and any custom extensions documented.
• SMART readiness: working discovery endpoints, granular scopes, and at least one reference client the vendor can run on the call.
• Testability: sample data sets, sandbox tenants, and deterministic test patients (e.g., consistent allergies or labs) so your automation stays stable.
• Performance: published rate limits, pagination behavior, and batch strategies. Bonus if they support Subscriptions for event-driven flows.
• Data governance: export pathways (including your right to extract data if you leave), BAAs, and attestations (SOC 2/HITRUST) without hand-waving.

Little habits that reduced my integration headaches

• I keep a one-page capability rubric—FHIR resources, SMART flows, bulk export, eventing—and ask every vendor to fill it out in writing.
• I run an early terminology sanity check on a handful of Observations (LOINC), medications (RxNorm where available), and allergies (SNOMED/REACTION coding) before committing to timelines.
• I document a patient identity strategy on day one (MRN vs. enterprise ID vs. payer member ID) so we don’t “discover” mismatches in UAT.

Speed traps and hidden costs I watch for

Here are the patterns that slowed me down most:

• Opaque write paths: Reads are “open,” but writes require custom contracts. That’s not necessarily a deal-breaker, but it belongs in your plan and price.
• Version drift: A vendor says “FHIR-compatible” but means R3 with ad-hoc extensions. Mapping that forward adds cost you rarely recoup.
• Scope sprawl: Over-permissive scopes patched by network firewalls. Least-privilege within the app is what actually reduces risk.
• No real sandbox: Demo data hidden behind NDAs and conference calls. If testing is hard, production will be harder.

Signals that tell me to slow down and double-check

• Security red flags—no PKCE, unclear token lifetimes, or missing revocation endpoints.
• Data quality surprises—units on vitals that flip between mg/dL and mmol/L, or missing LOINC codes on labs.
• Contractual friction—language that limits your right to export or keep a running copy of records you create.
• Compliance posture—vague references to “HIPAA compliant” without describing controls, audits, or incident response.

When I see any of these, I reach for authoritative docs before I make a call. The FHIR overview clarifies the “shape” of data we should expect, the SMART spec shows what scope discipline looks like, and ONC’s standardized API pages explain what certified EHR APIs must offer (ONC API criterion).

What I’m keeping and what I’m letting go

I’m keeping a bias toward boringly standard over “clever” when it comes to APIs. I’m keeping written rubrics, live SMART demos, and one-page profiles of resource coverage before a contract. I’m letting go of the idea that “telehealth features” matter more than integration; the best features with brittle data are still brittle. And I’m letting go of vendor-specific magic that can’t be exported if our needs change in a year.

FAQ

1) Do I need FHIR if my telehealth platform already integrates with my EHR?
Answer: Maybe yes, maybe no. If your current integration is stable and documented, you can live on it. FHIR becomes valuable when you want portability, standardized data shapes, or to add new apps without rebuilding. A quick way to decide is to list which data you frequently exchange (e.g., allergies, meds, vitals) and see how closely they map to US Core.

2) Is SMART on FHIR required for telehealth?
Answer: Not in all cases, but it’s a practical way to handle secure authorization and context for clinician-facing or patient-facing apps. If a vendor supports SMART, your future app choices broaden and your security model is easier to reason about. See the spec for patterns and scope examples (SMART App Launch).

3) Which FHIR version should I ask for?
Answer: In the U.S., R4/R4B remains the most practical baseline for EHR and app compatibility. Ask vendors to state their supported version, which US Core profiles they implement, and how they plan to handle upgrades and backward compatibility.

4) How do payer APIs affect telehealth?
Answer: CMS rules are pushing payers to expose FHIR-based patient access and provider access APIs. That can streamline eligibility, prior authorization status, and clinical data exchange around telehealth episodes. It’s not instant, but it’s moving the ecosystem toward easier, standards-based connections (CMS rule overview).

5) What about HIPAA—does an “open API” create risk?
Answer: Any API can create risk if designed poorly. The safer posture is standards-based (SMART on FHIR with OAuth 2.0 and PKCE), least-privilege scopes, strong auditing, and contractual clarity on data handling. Open APIs done well can actually reduce risk by avoiding ad-hoc, opaque integrations.

Sources & References

• HL7 — FHIR Overview
• HL7 — SMART App Launch (v2.1.0)
• ONC — Standardized API for Patient and Population Services
• ONC — USCDI Overview
• CMS — Interoperability & Prior Authorization Final Rule (2024)

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).