Platform Overview

Vim Connect puts your application inside the EHR, at the point of care, without you integrating with each EHR individually. You build once against the Vim Connect App SDK; Vim handles the per-EHR differences.

Where your app runs

Your app is a web app you host, loaded in an iframe inside the Vim Connect overlay — a layer that sits on top of the provider's EHR. Providers open it from the Vim Hub, a strip of app icons anchored in the EHR window.

Because your app is an ordinary hosted web app, you keep your existing stack. The SDK is JavaScript/TypeScript, but your backend can be written in anything.

Two app shapes

A UI app renders an interface the provider opens and interacts with. A Worker App runs headless in a hidden offscreen document — no UI — receiving the same EHR events so it can process data or raise notifications without the provider opening anything. Many products ship both.

What the SDK gives you

Capability	What it means for you
Normalized EHR access	Read patient, encounter, order, referral and claim data through one shape, regardless of the underlying EHR. See EHR Connectivity.
Workflow events	React to what the provider is doing — chart open, encounter open — instead of polling. See Workflow Events.
Writeback	Write structured data back into the chart, with provider consent. See Writeback.
Hub presence	Control your icon's state, badge count and push notifications. See Vim Hub.
Authentication	A standard authorization-code exchange; Vim issues the tokens. See Authentication.

You do not write EHR-specific code. Vim's adapters do the extraction and writeback per EHR, and the SDK exposes one normalized surface.

Which EHRs you reach

Vim Connect currently reaches these EHRs. Building once against the SDK covers all of them — you do not integrate with each one separately.

Azalea
DrChrono
eClinicalWorks (Web)
Elation
Kareo Tebra
Practice Fusion
Sandbox EHR

Coverage differs by EHR — an event or field supported in one may not be available in another. The EHR Support Matrix is the authoritative, always-current view of which events, fields and API operations each EHR supports.

Check it before you finalize the EHR scopes in your manifest. The most common avoidable mistake is depending on a field that your target EHRs don't expose.

Platforms and browsers

Vim Connect runs alongside the EHR on the clinician's desktop. Confirm your users are on a supported combination before you pilot.

Surface	Supported
Web browsers	Chrome and Edge, on Windows, macOS and Linux.
Desktop software	Windows only. A web plugin is available for eCW plugin mode.
iPad and mobile	Not supported.

Design for desktop

There is no mobile runtime, so an app that assumes a phone or tablet viewport will not reach users. Build for a desktop browser panel alongside the chart.

PHI and PII boundaries

Vim treats patient-identifying data as opt-in. Your app declares the EHR data it needs in its manifest, and an Allowed PII setting governs whether identifying fields are included in what you receive.

With Allowed PII off, identifying fields — names, contact details, dates of birth, member IDs, free-text clinical notes — are stripped before your app sees them.
With Allowed PII on, those fields become selectable, and your app must justify each one during review.
Non-identifying structured data — problem lists, medications, procedure codes, statuses — is unaffected.

Request the narrowest set of fields your product actually needs. Review scrutinizes scope, and narrower scope is faster to approve.

From account to live app

Get access — you're invited to the Vim Console with a developer facet.
Create an app and fill in its manifest — identity, hub UX, EHR scopes.
Get credentials by creating an environment; this is where your client ID and secret come from.
Build and test against the Sandbox EHR, a real EHR instance reserved for you.
Submit for review. Vim checks security, compliance and store-listing content.
Mark the approved version live when you're ready to ship.

Managing Your Developer Account walks through every step in the Console. If you'd rather write code first, start with the Quick Start.

Terminology

Term	What it means
Vim Connect	The overall platform — the technology that embeds your app into the EHR at the point of care and normalizes the data and events it exposes to you.
Vim Console (or Console)	The self-service web app where you create and manage apps, manifests, environments, users, and (for provider organizations) EHR connections and settings.
Vim Connect extension	The Chrome extension that injects the overlay and Vim Hub into the EHR page. Without it installed and signed in, there is nothing for your app to load into — see Testing against the Sandbox EHR.
Vim Hub	The strip of app icons anchored in the EHR window that a provider opens your app from. Your manifest's App UX settings control what it shows for your app — badge, tooltip, push notifications. See Vim Hub.
Sandbox EHR	A Vim-owned, working EHR instance with synthetic patients and no real PHI, reserved for your account. The only place to exercise your app end to end before submitting it for review.
App	A container you create in Build → My Apps. It isn't versioned itself — its versions are.
Version	A numbered, independently-configured snapshot of an app (`v1`, `v2`, …), each with its own manifest and submission answers, moving through Draft → In Review → Pending release → Live (or Declined).
Manifest	The configuration for a version — identity metadata, App UX capabilities, EHR scopes, and Entity Store settings — filled in across the manifest editor's tabs.
Environment	A named set of credentials (client ID and secret) and optional endpoint overrides for one deployment target, e.g. `Local`, `Staging`, `Production`. Credentials belong to the environment, not the app.
UI App	An app that renders an interface a provider opens and interacts with in the Hub.
Worker App	An app that runs headless in a hidden offscreen document — no UI — receiving the same EHR events so it can process data or raise notifications without the provider opening anything. See Worker Apps.
Developer facet	The capability on your Console account that reveals the Build section (My Apps, Sandbox EHR, Resources). Granted when you accept a developer invitation.
PHI / PII	Protected/personally-identifying information from the EHR. Your manifest's Allowed PII setting governs whether identifying fields are included in what your app receives — see PHI and PII boundaries above.