FHIR-native, EHR-agnostic.
Most EHR integration failures come from the same root cause. Vendors build for one EHR, then bolt on the others. We did it the other way. The data mapping layer is the product. FHIR, HL7 v2, and 837/835 EDI all converge to the same internal canonical model. Downstream AI Suite tools never see the EHR-specific quirks. Onboarding a new customer on a supported EHR takes weeks, not quarters.
Native, fallback, or clearinghouse.
Every supported EHR ships with three reuse paths. Native FHIR is the gold path, used when the EHR offers SMART on FHIR or a marketplace FHIR R4 endpoint. HL7 v2 is the fallback, used when FHIR support is partial or restricted to read-only resources. The 837/835 EDI clearinghouse path is the catch-all, used for the older EHRs and for direct payer connectivity.
The matrix is the partial list. Under NDA we share the full EHR coverage map including the unannounced upcoming integrations and the specialty-specific EHR vendors (ABA platforms, behavioral health EHRs, dental practice management systems).
Six capabilities. One data mapping layer.
The downstream AI Suite tools (eligibility, prior auth, claim status, denial management, posting, coding) never see EHR-specific structure. The data mapping layer normalizes every inbound message into the canonical internal model.
Read and write, both ways.
Six EHRs run bidirectional FHIR R4. We read Patient, Encounter, Coverage, Condition, Procedure, ServiceRequest, DocumentReference, Practitioner, Organization. We write Claim, CommunicationRequest, and Task back. SMART on FHIR for the Epic and Cerner OAuth dance.
ADT, ORM, ORU, DFT inbound.
For EHRs without complete FHIR coverage, HL7 v2 messages flow through the mapping layer. ADT for patient demographics and encounters, ORM for orders, ORU for results, DFT for charges. Message integrity validation and acknowledgement back to the EHR.
Clearinghouse or direct.
837 (claim submission) and 835 (electronic remittance advice) via the major clearinghouses: Availity, Change Healthcare, Optum, Waystar, Office Ally, Trizetto. Direct payer EDI where the payer offers a private endpoint. 277 and 999 round-trip into the same workflow.
PKCE, tokens server-side.
SMART on FHIR authorization code flow with PKCE for the EHR side, OAuth2 client credentials for the system-level integration. Access tokens are short-lived (60 minutes typical). Refresh tokens held server-side only. No tokens ever land in browser local storage.
Real-time, no polling.
Where the EHR publishes webhook events (Epic backplane, Cerner subscription resources), we consume them in real time. Patient demographic changes, new encounters, new orders all trigger downstream workflow updates within seconds rather than waiting for a polled refresh cycle.
Canonical model, per-EHR mappers.
Every inbound message normalizes to the canonical internal model (Patient, Encounter, Coverage, Claim, Practitioner, Organization). Mappers live as versioned TypeScript modules with test fixtures per mapping. When an EHR upgrades its FHIR profile, the mapper version bumps and downstream code stays unchanged.
Chart open to coder review. One pass.
From the moment a clinician opens a chart in the EHR, here is the integration path the data takes through the ASP-RCM stack on its way to a coder review queue.
Chart open in EHR
SMART on FHIR launch context tells us the patient ID, encounter ID, and the practitioner identity. The OAuth2 access token attaches to the API request.
Mapping layer normalizes
FHIR Bundle fetch retrieves Patient, Encounter, Coverage, Condition, Procedure, DocumentReference. Mapper normalizes to canonical model. Encrypted in-memory cache holds the bundle.
AI prompt sub-second
Coding suggestion, eligibility status, prior auth gap, documentation gap, denial risk. Streams from cache in under 400ms p95. Prompt versioning logged per request.
Coder review queue
AI confidence below threshold routes to coder review. Coder accepts, rejects, or edits. Decision feeds back into the model retraining loop. Audit trail in phi_access_log.
Four steps. Weeks, not quarters.
A new customer on a supported EHR comes online on a documented timeline. Here is the work the integration team executes from kickoff to production cutover.
Sandbox connectivity.
EHR vendor provisions sandbox tenant. We register the OAuth2 client, exchange certificates if needed, and validate the FHIR endpoint reachability. Test fixtures verify the mapper produces a clean canonical model.
Production tenant provisioned.
EHR vendor provisions production tenant. Customer admin approves the OAuth scopes. We rotate the client secret into Secrets Manager and run a production smoke test against a synthetic patient.
Data flow validation.
Real customer data flows through the mapping layer for 5 to 10 business days. Mapper edge cases get logged. Customer reviews a sample of normalized records side-by-side with the EHR view to confirm fidelity before cutover.
Cutover + monitor.
Downstream AI Suite tools and Credential OS switch from manual data entry to live EHR feed. First 30 days carry double-monitoring: any mapper failure or data anomaly is human-reviewed before the workflow proceeds.
Measured. Per customer.
Telemetry from production EHR tenants, last 90 days. Numbers come from the API gateway metrics and the mapping layer test suite.
Frequently asked questions: EHR integration.
Which EHRs does ASP-RCM natively support via FHIR?
What about EHRs without FHIR support?
How fast are in-chart prompts?
What is the OAuth2 setup like?
Do you support 837/835 EDI?
How does the data mapping layer work?
How long does an EHR integration take to spin up?
How does this connect to Credential OS and the AI Suite?
Send your EHR fingerprint. We send back the fit assessment.
Tell us your EHR vendor, version, current clearinghouse, and the AI Suite tools you want to deploy. Under NDA we return a fit assessment covering connectivity path, integration timeline, mapper coverage of your specialty, and any gaps that need customer-side configuration. A senior partner on the call.