SignalEDI PA Bridge · CMS-0057-F
Why teams evaluate SignalEDI
Illustrative example based on representative SignalEDI usage — not a named customer endorsement.
Evaluate without a sales call
Most buyers are not ready to buy on the first visit. Start with a free tool or requirement check — then trial when you are ready.
What is SignalEDI?
Quick answer
The compliance clock
January 1, 2026
Already enforceable
72-hour expedited and 7-calendar-day standard decision windows, specific denial reasons, and annual public reporting of prior-authorization metrics are already in force for impacted payers.
January 1, 2027
Compliance deadline
The Prior Authorization API (Da Vinci PAS, with CRD and DTR), Patient Access, Provider Access, and Payer-to-Payer APIs must be in production, with enforcement that includes financial penalties and program-participation impact.
CMS enforcement discretion informs the target architecture, but it does not change PA Bridge release status. The design-partner sandbox evaluates FHIR and X12 intake with synthetic data; production X12 dispatch remains roadmap.
How it works
Shipped PAS endpoints and X12 278 intake map into one canonical authorization record. The deterministic sandbox demonstrates the workflow; production X12 dispatch remains roadmap.
Shipped PAS endpoints
Providers and their EHR vendors call Da Vinci PAS endpoints: POST /Claim/$submit and /Claim/$inquire. SMART backend-services authentication (client-credentials JWT) and rate limiting are on from the first request, and malformed payloads come back as a FHIR OperationOutcome instead of a silent failure.
Shipped canonical model
Shipped PAS requests and X12 278 intake map into the same canonical authorization record with an event timeline. That model is the foundation for, not proof of, the roadmap production round-trip.
Sandbox now; production roadmap
The deterministic sandbox uses a mock UM responder to demonstrate decisions on synthetic records. Dispatch onto live X12 278 connections and the production response path are roadmap capabilities.
Who it serves
You own the deadline and the penalty exposure. PA Bridge is scoped compliance: a FHIR surface in front of the UM stack you already trust, fail-closed tenant isolation with an event timeline on every authorization, and a feature grid on this page that tells you plainly what is shipped and what is not.
You get endpoints, not a statement of work: SMART backend-services auth, JSON in and out, deterministic sandbox data you can replay byte-for-byte, and a mock UM responder you can drive to approve, pend, or deny.
Authorizations from FHIR and 278 land on one record with one event timeline per request, whichever dialect the provider spoke. The operations dashboard and statutory SLA clocks on the roadmap build on that same record.
Shipped vs. roadmap
Compliance timelines punish vendors who blur this line, so we keep it explicit: a capability is labeled shipped only when the code is in the product.
Live FHIR R4 endpoints with SMART backend-services (client-credentials JWT, RS256/RS384) authentication, per-IP rate limiting, and OperationOutcome error semantics.
A 005010X217 intake rulepack maps inbound X12 278 requests into the canonical authorization model. Production outbound dispatch remains roadmap.
PAS bundles and 278 transactions both map into a single authorization record with an event timeline, giving every request one source of truth.
Deterministic synthetic members, providers, and authorizations plus a mock UM responder that approves, pends, or denies on demand. Available to design partners today.
Only a UM response can set a decision status. Neither AI nor mapping code can approve or deny an authorization.
Prior-authorization records deny access unless tenant context matches, and the event timeline is append-only by policy.
Production dispatch of 278 requests onto live UM connections, completing the FHIR-to-X12 round-trip outside the sandbox.
Per-request 72-hour and 7-day clocks, escalation webhooks, breach forecasting, and an operations dashboard.
An operations UI for searching authorization timelines, working mapping and validation exceptions, and resubmitting from a reviewed failure point.
Prior-authorization approval, denial, and decision-time metrics with export and an optional hosted public page.
Da Vinci PAS, CRD, and DTR test suites with timestamped evidence reports.
Coverage-requirements discovery and DTR questionnaire/CQL hosting.
X12 275 attachment handling and AI extraction into DTR answers, with human confirmation on clinical fields.
The remaining CMS-0057-F access APIs, including bulk PA-history export and import jobs for member migration.
Why it is different
Test the shipped PAS endpoints against synthetic data before a production commitment. Evaluation records the path from credentials to a successful sandbox request without promising a universal completion time.
The shipped canonical model represents PAS requests and X12 278 intake in one authorization record. Production bidirectional translation remains tied to the outbound-dispatch roadmap item.
PA Bridge follows a platform-fee plus per-authorization model. Numeric tiers remain private during the design-partner phase and publish only after the general-availability commerce gate opens.
AI in PA Bridge extracts, classifies, maps, and drafts. It does not approve, deny, or recommend disposition of an authorization, and that rule is enforced in the write path, not just stated in a policy document.
For SignalEDI EDI customers
PA Bridge is a section of the SignalEDI platform, not a second vendor. For organizations already running SignalEDI EDI, turning it on is an entitlement change on your existing tenant — not a migration project.
PA Bridge runs in the same workspace, on the same tenant, under the same billing relationship as your EDI plan. Your team signs in once and finance sees one SignalEDI invoice.
The partners, connections, and X12 rails you configured for EDI keep working. Prior authorization rides the same unified core as your other X12 traffic, so there is no partner re-onboarding.
Already on SignalEDI EDI? PA Bridge remains an add-on on the same tenant and billing relationship. Public numeric pricing stays closed until general availability.
Authorizations land beside your existing EDI activity: one canonical record per request, one event timeline, one place your operations team already checks.
Numeric tiers remain private during the design-partner phase. Public pricing opens only with the general-availability commerce gate.
For integration engineers
This is the live endpoint shape, not pseudocode. Send a Da Vinci PAS request bundle and get back a FHIR ClaimResponse tied to the canonical authorization record.
curl -X POST https://signaledi.com/api/fhir/r4/Claim/\$submit \
-H "Authorization: Bearer $SMART_CLIENT_JWT" \
-H "Content-Type: application/fhir+json" \
-d @pas-request-bundle.json
# 200 → FHIR ClaimResponse with the authorization id and status
# 422 → OperationOutcome naming the failing element, never a silent dropAuthentication is SMART on FHIR backend services: sign a client-credentials JWT (RS256 or RS384) with the key registered for your client and present it as the bearer token. In the sandbox, the bootstrap endpoint registers your client with public key material you supply.
More on keys, webhooks, and sandbox workflows in the developer platform.
Impacted payers (Medicare Advantage plans, Medicaid and CHIP managed care, QHP issuers on the federally-facilitated exchanges) must operate FHIR Prior Authorization, Patient Access, Provider Access, and Payer-to-Payer APIs by January 1, 2027. Decision-turnaround rules (72 hours expedited, 7 calendar days standard), specific denial reasons, and public metrics reporting have applied since January 2026.
No architectural replacement is assumed during design-partner evaluation. The shipped sandbox maps PAS requests and X12 278 intake into one canonical model with a mock UM responder; production dispatch to a live UM connection remains roadmap.
PA Bridge is in its design-partner phase. The PAS endpoints with SMART backend-services auth, the X12 278 rulepack, the canonical model with fail-closed tenant isolation and a decision write guard, and the deterministic sandbox with a mock UM responder are in the product today. The outbound X12 dispatch rail, SLA engine, exception workbench and explorer, CMS metrics reporting, conformance harness, CRD/DTR, attachments, and access APIs are on the roadmap. Email support@signaledi.com for sandbox access or design-partner details.
No. Decisions come only from your UM system. A write-path guard enforces that only a UM response can set a decision status, and AI in the product is limited to extraction, classification, mapping, and drafting under human review.
PA Bridge is a prior-authorization add-on service on the SignalEDI platform, not a separate product: one login, one tenant model, one billing relationship, and the same unified core that runs SignalEDI's other X12 traffic. It adds prior-authorization rulepacks, FHIR endpoints, and payer workflows on top rather than standing up a separate system.
PA Bridge is in its design-partner phase, so no numeric tier is authorized for public use yet. The intended model is a platform fee per payer tenant plus per-authorization metering. Request sandbox or design-partner access to evaluate the shipped capabilities; public tiers publish only at general availability.
X12 278 (005010X217) is the HIPAA transaction set for prior-authorization requests and responses. Da Vinci PAS expresses the authorization conversation as FHIR resources through Claim/$submit and Claim/$inquire. In the PA Bridge design-partner phase, shipped PAS endpoints and X12 278 intake map into one canonical record; production outbound dispatch is roadmap.
Prior authorization EDI integration uses X12 278 for electronic authorization requests and responses. Under CMS-0057-F, impacted payers must also operate a FHIR Prior Authorization API by January 1, 2027. PA Bridge currently offers design-partner evaluation of PAS endpoints, X12 278 intake, and a synthetic sandbox; live production dispatch is roadmap.
Request sandbox access to submit a Da Vinci PAS request against synthetic data and a mock UM responder, or write to the team about the design-partner program. Both start with one email.
Explore SignalEDI
Pricing, checkout, solutions, support, partner requirements, and trust artifacts stay linked so buyers do not dead-end on a single page.
© 2026 SignalEDI Inc. All rights reserved.