API and FHIR-native integration.
Six EHRs connected with native FHIR R4 bidirectional. Twelve more via HL7 v2 and 837 EDI for the long tail. A unified REST API in front of every engine in the platform. Webhook events, OAuth2 with RS256 JWT, sandbox plus production tenants, and per-tenant rate limits. Same mask-by-default, audit-log, and row-level RBAC discipline as the rest of the platform. No EHR is too old to connect.
Three tiers. One credential of truth.
The integration surface is a three-tier architecture. The edge layer handles TLS termination, rate limiting, and the RS256 passport verification. The gateway layer routes by tenant and endpoint, applies mask-by-default to PHI fields, and writes the audit-log row before the response returns. The service layer carries the engines: coding, eligibility, denial prediction, prior auth automation, CredPro v6 credentialing.
The architecture is what makes one credential of truth work across the platform. The same passport authorizes every call. The same audit log captures every PHI access. The same mask-by-default protects every response. A change in CredPro v6 provider enrollment fires a webhook the coding engine listens for and updates the three-way match before the next claim line runs.
Versioned endpoints. Predictable shapes.
The REST API in front of the engines. All endpoints are versioned. JSON envelopes are consistent. The example below is a redacted view of the most-used endpoints in the partner integration set.
{ status: active, copay: 30, ... }
{ lines: [{cpt, dx, mod, conf}] }
{ risk: 0.68, carc: CO-50, ... }
{ npi, name, tin: XXX-XX-1234 }
{ tin: 12-3456789 }
{ id, secret, events: [...] }
Six capabilities. One integration surface.
Each capability ships across sandbox and production. The promotion path is a tenant configuration change, not a code change. Partners build and verify in sandbox; production tenants pick up the same surface.
Six EHRs, native.
Native FHIR R4 with bidirectional resource read and write across Epic, Cerner/Oracle Health, Athena, NextGen, eClinicalWorks, and MEDITECH. Patient, Coverage, Encounter, Claim, CoverageEligibilityRequest/Response, Practitioner, Organization, ServiceRequest. Read clinical and eligibility context; write coding output and claim status back. HL7-FHIR compliant, not a screen-scrape with FHIR branding.
Unified surface, versioned.
Unified REST API in front of coding, eligibility, denial prediction, prior auth, and CredPro v6 credentialing. Same JSON envelope, same OAuth2 auth, same audit log, same mask-by-default. Endpoints versioned with deprecation policy. Webhook events for state changes, signed payloads with HMAC-SHA256, exponential-backoff retry, 7-day replay.
Twelve more EHRs, the long tail.
HL7 v2 handles clinical and demographic feeds for EHRs without FHIR endpoints: ADT for admit/discharge/transfer, SIU for scheduling, MDM for clinical documents, DFT for billing events. Twelve additional EHRs connect this way. No production EHR is too old to integrate.
Clearinghouse fallback, every payer.
837 for outbound claim submission, 835 for inbound remittance posting. Standard clearinghouse routes and direct payer connections. Acts as the final fallback for any EHR that exports an 837 even without FHIR or HL7 v2 endpoint. Same audit and validation layer applies to the EDI path as to the FHIR path.
Asymmetric tokens, short TTL.
OAuth2 client-credentials grant for service integrations, authorization-code with PKCE for user-facing apps. Access tokens are RS256-signed JWTs with short TTL: 15 minutes for user sessions, 5 minutes for service-to-service. Refresh tokens stored separately with their own audit trail. Asymmetric signing means partners verify with the public key, no shared secret distribution.
Same surface, isolated data.
Sandbox carries the same API surface, same auth, same FHIR shapes, synthetic test data covering 200 patient personas and 30 payer scenarios. Promotion to production is a tenant configuration change. Per-tenant rate limits at the gateway: 100 RPS sustained, 500 burst, with a separate higher-priority queue for eligibility 270s at the registration desk. 429 responses include retry-after headers.
Four phases. Thirty days standard.
From contract to production traffic. The four phases are what we run with every partner. Promotion between phases is gated; nothing automatic that the partner has not signed off on.
Sandbox setup.
Sandbox tenant provisioned with synthetic data. OAuth2 client credentials issued. Partner integration team gets API documentation, the FHIR shape reference for the connected EHRs, and the webhook event catalog. First call lands in the sandbox within 24 hours.
Build against the surface.
Partner builds against the sandbox. Same endpoints, same auth, same shapes as production. Synthetic data covers 200 patient personas, 30 payer scenarios, and the CARC patterns the denial engine watches for. Integration team available for review and clarification.
Verify the integration.
Acceptance test against the documented behavior: eligibility roundtrip, coding case roundtrip, denial score roundtrip, webhook delivery, mask and reveal boundaries, audit log entries. UAT report shared. Gaps fixed before promotion.
Promote to production.
Tenant configuration flips from sandbox to production. Production credentials issued. Real PHI flows under the security architecture documented. Production traffic ramps with monitoring on rate-limit headroom, error rates, and webhook delivery success. Standard partner integration runs in 30 days.
Measured posture from the API.
Across active integrations. Numbers below are honest measurement.
Frequently asked: API and FHIR.
What is the FHIR-native integration?
What about EHRs that do not have a FHIR endpoint?
What is the REST API surface?
How do webhook events work?
What does OAuth2 with RS256 JWT mean?
Is there a sandbox environment?
What is rate limiting and what are the limits?
How does the API integrate with CredPro v6?
Where the API routes.
The API surface is the integration entry point. Three engines it most often serves.
Provider credential of truth.
CredPro v6 is the credentialing platform behind the API. Mask-by-default on provider PHI, audited reveal, row-level RBAC, status webhooks that fire on enrollment change. Downstream coding picks up new active credentials before three-way match runs.
Read more → SecuritySame passport and audit log.
The API enforces the same RS256 passport, the same row-level RBAC, and the same PHI access log documented in the security architecture. One discipline at the gateway and again in the data access layer.
Read more → Eligibility AILive 270 at the front desk.
Eligibility verify is the highest-volume endpoint on the API. Higher-priority queue at the gateway ensures the front desk never sees queue-throttled responses. Sub-300ms P95 against 1,200+ payer adapters.
Read more →Need API access for an integration? Send us the use case.
We will provision a sandbox tenant within 24 hours, share the documentation, the FHIR shape reference for the connected EHRs, and the webhook event catalog. Standard partner integration runs in 30 days from sandbox to production. An ASP-RCM senior partner on the call.