Platform · Integrations
Mira™ Integrations.
Mira™ plays nicely. EMR sync, clearinghouse integration, SSO, telephony, accounting — connects to what you already run.
Integrations that your IT team can verify and your compliance team can audit.
Hospice organizations do not exist in isolation. Patient records originate in EMRs. Claims route through clearinghouses. Staff authenticate through enterprise identity providers. Revenue posts to accounting systems. Families and care teams communicate over SMS and voice. Every one of these touchpoints is a potential integration gap — a place where data must be re-entered, a place where a sync delay produces a stale claim, a place where a single sign-on failure locks a clinician out of a visit chart.
Mira™ treats integrations as first-class infrastructure, not bolt-on connectors. The EMR sync is OAuth-based with automatic token refresh — access tokens expire on the EMR provider's schedule; Mira™ rotates them without manual intervention. Clearinghouse connections are configured per payer, not per organization — so Availity handles Medicare Part A while Change Healthcare handles a specific commercial payer, and the routing is invisible to billing staff. SSO is SAML 2.0 and OIDC, with MSAL B2C for Microsoft/Azure AD organizations. Webhooks carry HMAC-SHA256 signatures so your downstream systems can verify payload authenticity without trusting the network.
Every integration event is logged in the same audit infrastructure as PHI access events. When a token refresh fails, the event is logged. When a webhook delivery is retried, the retry count and the last HTTP status code are logged. When a SAML assertion is rejected, the rejection reason is recorded. These logs are queryable by compliance officers alongside PHI audit events — no separate integration monitoring tool required.
Integration surfaces
- ✓ EMR sync — Epic + Cerner via OAuth; FHIR R4 Patient, Encounter, Observation; bidirectional write-back
- ✓ Clearinghouse — Availity + Change Healthcare; per-payer routing; 277/835 EDI processing
- ✓ SSO — SAML 2.0, OIDC, MSAL B2C; Azure AD, Okta, Google Workspace tested
- ✓ Webhooks + REST API — HMAC-SHA256-signed events; 24-hour retry with exponential backoff
- ✓ Accounting + telephony — QuickBooks revenue posting; Twilio outbound SMS + voice
What IT and dev teams ask for
- → "What FHIR version do you support?" — R4; Patient, Encounter, Observation, Condition resource types
- → "How do you handle token expiry?" — automatic refresh; no manual rotation; event logged on failure
- → "Can we route different payers through different clearinghouses?" — yes; per-payer routing table in admin
- → "What is your webhook signature scheme?" — HMAC-SHA256 over the full payload body; timestamp in header
- → "Do you support PKCE for OAuth flows?" — yes; all OAuth 2.0 flows use PKCE; no implicit grant
- → "Can we receive claim status events in real time?" — yes; claim.submitted, claim.adjudicated, payment.posted webhook events
OAuth 2.0 with PKCE. FHIR R4 Patient, Encounter, Observation. Bidirectional write-back.
EMR sync in Mira™ is OAuth 2.0 with PKCE — no client secrets stored in configuration files, no long-lived credentials that require rotation on a schedule. The initial authorization flow runs once; Mira™ stores the refresh token in the secrets manager and rotates the access token automatically before each API call. The access token lifetime is set by the EMR provider (typically 15–60 minutes); Mira™ refreshes it without surfacing the expiry to the user or the billing staff.
Inbound sync reads FHIR R4 resources: Patient (demographics, identifiers, payer coverage), Encounter (visit type, service dates, attending provider), Observation (vitals, functional status scores), and Condition (diagnosis codes). The sync is incremental — Mira™ requests resources modified since the last successful sync timestamp, not a full export on every run. Sync failures are logged with the resource type, the FHIR operation URL, and the HTTP status code returned by the EMR.
Bidirectional write-back posts claim status updates back to the EMR as FHIR ClaimResponse resources. When a claim is adjudicated and a payment is posted in Mira™, the write-back fires automatically — no manual step, no export-import cycle. Epic and Cerner both expose write-back endpoints under their SMART on FHIR authorization frameworks; Mira™ uses the same OAuth session for reads and writes.
- – OAuth 2.0 + PKCE; access tokens refreshed automatically; refresh tokens stored in secrets manager
- – FHIR R4 resources: Patient, Encounter, Observation, Condition; incremental sync from last-modified timestamp
- – Sync failures logged with resource type, FHIR operation URL, HTTP status; visible in admin event log
- – Bidirectional write-back: ClaimResponse posted to EMR on adjudication; same OAuth session as reads
Mira product screenshot with numbered annotations. 1 2 - 1 OAuth-based Epic / Cerner connection. Tokens refresh automatically.
- 2 Bidirectional write-back: claim status, vitals, encounter notes.
Mira product screenshot with numbered annotations. 1 - 1 Availity + Change Healthcare configured per payer.
Per-payer clearinghouse routing. 277/835 EDI processing. Real-time eligibility across both.
Clearinghouse routing in Mira™ is configured at the payer level, not the organization level. A Medicare Part A claim routes through Availity. A specific commercial payer routes through Change Healthcare. A state Medicaid program routes through a third EDI gateway. The routing table is managed in the admin panel; billing staff see only the submitted status — the clearinghouse selection is invisible to them and consistent every time.
Claim submission generates ASC X12N 837P or 837I transactions depending on claim type. Status polling uses the 276/277 transaction pair — Mira™ sends a 276 Claim Status Request and processes the 277 Claim Status Response to update the claim record. ERA processing handles the 835 Health Care Claim Payment/Advice to post line-item adjustments, contractual allowances, and patient responsibility amounts. The 835 processing runs against the claim's original 837 to match adjustment reason codes to the corresponding claim lines.
Real-time eligibility verification runs through both Availity and Change Healthcare depending on the payer. The 270/271 transaction pair returns benefit details including deductible, co-pay, co-insurance, and out-of-pocket maximum. The eligibility result is attached to the patient record and surfaced inline on the claim builder — billing staff see the verification result without leaving the claim.
- – Per-payer routing table in admin; billing staff see status only — routing is transparent
- – 837P / 837I claim submission; 276/277 status polling; 835 ERA posting with line-item matching
- – Real-time 270/271 eligibility: deductible, co-pay, co-insurance, out-of-pocket maximum
- – Availity + Change Healthcare both active; payer determines which is used at submission time
SAML 2.0, OIDC, and MSAL B2C. Azure AD, Okta, and Google Workspace tested.
Staff authentication in Mira™ uses Microsoft Authentication Library (MSAL) with Azure B2C as the identity broker. B2C supports federation to any SAML 2.0 or OIDC-compatible identity provider — including Azure AD (Entra ID), Okta, Google Workspace, and any on-premises ADFS deployment. Organizations that already have an enterprise IdP do not need to provision separate Mira™ credentials for their staff; authentication flows through the existing IdP and the session token is issued by B2C.
SAML 2.0 federation uses a service provider metadata URL published by Mira™'s B2C tenant; the IdP administrator adds Mira™ as a relying party using this metadata. Attribute mapping maps the IdP's user identifier, email, display name, and group memberships to Mira™'s user profile. Group-to-role mapping is configured in the Mira™ admin panel — an Azure AD security group maps to a Mira™ clinical role; an Okta group maps to a billing role. The mapping is evaluated on every login; role changes in the IdP take effect at the user's next sign-in.
OIDC federation follows the authorization code flow with PKCE. The ID token carries the standard claims (sub, email, name) plus any custom claims configured in the IdP application registration. Multi-factor authentication enforcement is handled at the IdP level — Mira™ does not bypass MFA requirements set by the organization's IdP policy.
- – MSAL B2C as identity broker; federates to any SAML 2.0 or OIDC IdP; no separate Mira™ credentials required
- – SAML 2.0: SP metadata URL published; attribute mapping for identifier, email, name, groups
- – Group-to-role mapping in admin panel; re-evaluated at each login; IdP group changes take effect at next sign-in
- – OIDC: authorization code + PKCE; MFA enforced at the IdP level; Mira™ does not bypass IdP MFA policy
Mira product screenshot with numbered annotations. 1 - 1 SAML 2.0, OIDC, MSAL B2C. Azure AD, Okta, Google Workspace supported.
Mira product screenshot with numbered annotations. 1 2 - 1 Sign payloads with HMAC-SHA256. Replay-protected via timestamp.
- 2 Failed delivery? 24-hour retry with exponential backoff.
HMAC-SHA256-signed payloads. 24-hour retry with exponential backoff. Full REST API documented at /developers.
Mira™ webhooks carry an X-Mira-Signature header containing an HMAC-SHA256 digest of the request body, keyed with a shared secret generated at webhook registration. The digest is computed over the raw byte body before JSON parsing — so signature verification does not depend on key ordering or whitespace normalization in the consumer. A X-Mira-Timestamp header carries the Unix timestamp of the delivery attempt; consumers should reject deliveries where the timestamp is more than 300 seconds old to prevent replay attacks.
Failed deliveries — any HTTP response outside the 2xx range, or a connection timeout — are retried with exponential backoff: 30 seconds, 2 minutes, 8 minutes, 30 minutes, 2 hours, 8 hours, then hourly until 24 hours after the initial delivery attempt. After 24 hours without a successful delivery, the event is marked as permanently failed and appears in the webhook dead-letter queue in the admin panel. Dead-letter events can be replayed manually after the endpoint issue is resolved.
The REST API follows JSON:API conventions. All resources are versioned under /api/v2/. Authentication uses bearer tokens obtained via the MSAL B2C OIDC flow — the same token that authenticates the web application authenticates API calls. API rate limits are 1,000 requests per minute per organization by default; the limit appears in X-RateLimit-* response headers. The OpenAPI 3.1 specification is published at the developer portal.
- – HMAC-SHA256 signature over raw request body; X-Mira-Signature + X-Mira-Timestamp headers on every delivery
- – Replay protection: reject deliveries where X-Mira-Timestamp is >300 seconds old
- – Retry schedule: 30s → 2m → 8m → 30m → 2h → 8h → hourly to 24h; dead-letter queue in admin panel
- – REST API: JSON:API, /api/v2/, bearer token auth; 1,000 req/min default; OpenAPI 3.1 at /developers
QuickBooks Online for revenue posting. Twilio for outbound SMS and voice. Both via webhook event.
Payment posting in Mira™ fires a payment.posted webhook event. The QuickBooks integration consumes this event and creates a sales receipt or invoice payment in QuickBooks Online using the QuickBooks Accounting API v3. The mapping between Mira™'s payment record and QuickBooks' income accounts is configured in the admin panel — each payer maps to a QuickBooks income account so revenue is categorized correctly without manual journal entries.
Authentication with QuickBooks Online uses OAuth 2.0 with the QuickBooks authorization server. The refresh token lifetime is 100 days; Mira™ refreshes access tokens automatically and alerts the admin panel when a refresh token is within 14 days of expiry — giving administrators time to re-authorize before the connection lapses. The QuickBooks company ID is stored per Mira™ organization; multi-entity accounting configurations (multiple QuickBooks companies) are supported with one QuickBooks connection per Mira™ organization.
The Twilio integration handles outbound SMS and voice for care team communication workflows: appointment reminders, medication reminder prompts, and family notification messages. Twilio Messaging Service SIDs are configured per organization; phone number provisioning and number pools are managed in the Twilio console. Message delivery status webhooks from Twilio are consumed by Mira™ and logged against the patient communication record — delivered, undelivered, and failed statuses are all visible to care coordinators.
- – QuickBooks Online v3 API; payment.posted event triggers sales receipt creation; payer-to-account mapping in admin
- – QuickBooks OAuth 2.0; 100-day refresh tokens; admin alert at 14-day-before-expiry; multi-entity supported
- – Twilio Messaging Service SIDs per org; outbound SMS + voice for appointments, medications, family notifications
- – Twilio delivery status webhooks logged against patient communication record; delivered/undelivered/failed visible to coordinators
Mira product screenshot with numbered annotations. 1 - 1 QuickBooks for revenue posting; Twilio for outbound SMS + voice.
Walk through the integrations workflow in 60 seconds.
Overview → Epic OAuth setup → record arrives → claim builds → webhook fires → status returns to EMR. Six steps.
Integrations overview
Connect Epic, Cerner, Availity, Change Healthcare, Azure AD, Okta, Twilio, QuickBooks.
How integrations fit the bigger picture.
Mira™ AI
The AI features that analyze claims, draft IDG briefs, and predict denials all operate on data that arrives through the EMR sync. The richer the incoming FHIR resource set, the more context the AI has. Integrations are the supply chain for Mira™ AI.
Explore AI →Mira™ Compliance
Integration events — token refresh failures, webhook delivery failures, SAML assertion rejections — are logged in the same immutable audit trail as PHI access events. Compliance officers can query integration events alongside clinical access events without a separate monitoring tool.
Explore Compliance →Developer portal
The REST API and webhook event catalog are documented in detail at the developer portal. OpenAPI 3.1 specification, webhook event schemas, authentication flows, rate limit headers, and sandbox credentials — all available without a sales conversation.
Go to API docs →Ready to review Mira™'s integration architecture with your IT team?
We support technical reviews: OAuth scopes, FHIR resource mapping, SAML federation metadata, webhook signature verification. Bring your integration engineer. 45 minutes, no slides.