Skip to content
VitalFax

Product

ProductIntegrationsDevelopersPricingFree toolsPartners

Industries

HealthcareTherapy practicesHome health & hospiceLegal & records

Trust

Trust CenterSecurityComplianceSubprocessorsStatus

Company

AboutBlogFree toolsPartner programmeHelp centreContact
Sign inCreate an account
Integrations

Two transports work today. The rest are interfaces, and we will say so.

A connector page that lists every EHR logo tells you nothing about whether the product can actually reach them. This page tells you which transports carry a document today, which are wired up but not connected, and exactly what each one is waiting on.

Transports

Communication channels

Fax

Send and receive fax on numbers assigned to your organization.

Available

Nothing outstanding — this works for every customer today.

Secure VitalFax Exchange

Send documents by expiring, access-logged link instead of fax.

Available

Nothing outstanding — this works for every customer today.

Direct Secure Messaging

Exchange messages with Direct addresses across the healthcare trust network.

Requires a vendor agreement

Required before this can work

  • A contract with a HISP (Health Information Service Provider).
  • Organization identity proofing to the level the HISP requires.
  • Issued Direct addresses and trust-anchor configuration.

FHIR

Read and write DocumentReference, Binary, Patient and Task resources.

Requires a vendor agreement

Required before this can work

  • A FHIR R4 endpoint from the partner organization.
  • A registered SMART client with the required scopes.
  • Agreement on which resources may be written.

EHR connections

Vendor-specific integrations for document delivery into the chart.

Requires a vendor agreement

Required before this can work

  • A vendor integration agreement and sandbox access.
  • Vendor-issued credentials for each customer site.
  • Vendor review or certification where required.

First-party

SendClinic connects through our own API

SendClinic is ours, so it integrates through the VitalFax public API rather than through a partner programme. Nobody else has to approve it. That is a different kind of integration from the vendor list below, which is why it is not in that list.

SendClinic

Native / first-party

SendClinic is ours. It integrates through the VitalFax public API rather than through anybody’s partner programme, so there is no vendor review standing between it and a working connection.

How it connects

SendClinic → VitalFax REST API → fax and provider layer

Ready now

  • Organization-scoped API keys, with the same permission model the interface uses.
  • REST endpoints for sending a fax and retrieving stored documents.
  • Signed webhooks for transmission and delivery events.

Not yet

  • The SendClinic-side connector is not shipped, so no customer can switch this on yet.
  • Until it is, this describes the integration path rather than a live connection.
Read the API docs

EHR systems

No EHR is connected

VitalFax has a generic connector contract that any of these would implement. It has no integration agreement with any of them, so none of them is connected. The list below describes the market, not a partnership.

Read this before assuming

Naming a vendor here is not a claim of certification, partnership, listing, or availability. Each entry records what VitalFax would need to obtain before writing any code against that system.

Epic

Vendor program required

Likely mechanism

FHIR R4 APIs, Vendor app listing and review

Requires

  • Registration in the vendor developer programme.
  • App review before production credentials are issued.
  • Per-customer authorization at each health system.

Oracle Health (Cerner)

Vendor program required

Likely mechanism

FHIR R4 APIs, Vendor developer programme

Requires

  • Developer account and app registration.
  • Per-tenant authorization by the health system.

athenahealth

Vendor program required

Likely mechanism

Partner APIs, FHIR APIs

Requires

  • Marketplace or partner agreement.
  • Per-practice enablement.

eClinicalWorks

Vendor program required

Likely mechanism

Vendor interface programme

Requires

  • Interface agreement.
  • Per-practice configuration and fees.

NextGen Healthcare

Vendor program required

Likely mechanism

Vendor APIs, Partner programme

Requires

  • Partner agreement.
  • Per-practice enablement.

AdvancedMD

Vendor program required

Likely mechanism

Vendor APIs

Requires

  • Partner agreement.
  • Credentials issued per practice.

Veradigm (Allscripts)

Vendor program required

Likely mechanism

Developer programme APIs

Requires

  • Developer registration.
  • Per-practice authorization.

Greenway Health

Vendor program required

Likely mechanism

Vendor APIs

Requires

  • Partner agreement.

Tebra (Kareo)

Vendor program required

Likely mechanism

Vendor APIs

Requires

  • Partner agreement.

Build it yourself

The API is the integration that works today

Everything the interface does, your systems can do. Organization-scoped API keys, a REST API for sending fax and retrieving documents, and signed webhooks when something happens.

Read the API docsDiscuss an integration

How a connector gets added

  1. 1A customer or vendor relationship creates a real reason to build it.
  2. 2The vendor agreement, credentials and any required review are completed.
  3. 3The connector is implemented against the existing contract, so nothing else in the product changes.
  4. 4Its status changes from "not configured" to "connected" in your Integrations page, per organization.

Using something not listed? Tell us which system — demand is how we decide the order.