PA Bridge · CMS-0057-F
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 has stated (February 2024 enforcement discretion, still in effect) that it will not enforce the HIPAA X12 278 requirement against payers operating a FHIR Prior Authorization API. Externally you can be FHIR-first while your UM stack keeps speaking 278 internally. The translation layer is the product.
How it works
FHIR and X12 278 are two dialects of the same authorization conversation. PA Bridge translates between them through one canonical record instead of standing up a parallel gateway.
Providers call
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.
PA Bridge translates
Every request, FHIR or X12, becomes the same canonical authorization record with an event timeline. 278 to PAS is a translation inside one engine, not a second stack to license, map, and reconcile against the first.
Your UM decides
Your UM system keeps speaking X12 278 over the connections it already has, and decisions flow back onto the same canonical record and out to the provider as a FHIR ClaimResponse. In the sandbox today, a mock UM responder plays that role end to end; production dispatch onto your live 278 connections is the top item on the roadmap grid below.
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 rulepack on the same unified core that runs SignalEDI's other X12 traffic, so prior authorization is a transaction set, not a separate product line.
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 (same seed, identical data) plus a mock UM responder that approves, pends, or denies on demand. Available to design partners today.
A hard rule in the write path: only a UM response can set a decision status. Neither AI nor mapping code can approve or deny an authorization.
Every prior-authorization table enforces row-level security that denies access unless the tenant context matches — isolation fails closed, not open — and the event timeline is append-only by policy.
Production dispatch of 278 requests onto your live UM connections, completing the FHIR-to-X12 round-trip outside the sandbox. First in the build order.
Per-request 72-hour and 7-day clocks, escalation webhooks, breach forecasting, and an operations dashboard for the turnaround rules payers are already subject to.
An operations UI over the canonical record: search and drill into any authorization's event timeline, work mapping and validation exceptions, and resubmit from the point of failure.
Continuously computed prior-authorization metrics (approval and denial rates, average decision time) with export and an optional hosted public page.
Run Da Vinci PAS, CRD, and DTR test suites on demand, with timestamped evidence reports suitable for a CMS audit file.
Coverage-requirements discovery and DTR questionnaire/CQL hosting to complete the prior-authorization API set.
The remaining CMS-0057-F access APIs, including bulk PA-history export/import jobs for member migration.
X12 275 attachment handling and AI extraction of clinical documents into DTR answers, with human confirmation required on every clinical field.
Why it is different
Incumbent gateways sell a demo, an RFP, and a statement of work. PA Bridge inverts that: test the actual PAS endpoints against synthetic data before you commit. We measure the time from credentials to a first successful sandbox round-trip and design for under an hour.
A FHIR gateway bolted next to an X12 stack means two architectures to keep in sync forever. In PA Bridge, 278 and PAS are two dialects of one authorization conversation inside one engine.
PA Bridge follows the same catalog philosophy as the rest of SignalEDI: a platform fee per payer tenant plus per-authorization metering, published on the pricing page at general availability rather than hidden behind a quote cycle.
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 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. CMS enforcement discretion (announced February 2024, still in effect) means payers operating a FHIR Prior Authorization API will not be pursued for the HIPAA X12 278 requirement externally. PA Bridge translates between the two, so your UM system keeps its 278 workflow while providers see FHIR.
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.
It is the same platform: one login, one tenant model, one billing relationship, and the same unified core that runs SignalEDI's other X12 traffic. PA Bridge adds prior-authorization rulepacks, FHIR endpoints, and payer workflows on top rather than standing up a separate system.
Pricing follows the published SignalEDI catalog model: a platform fee per payer tenant plus per-authorization metering. Exact tiers publish on the pricing page at general availability; design partners see pricing first and are never asked to price a mystery.
X12 278 (005010X217) is the HIPAA transaction set for prior-authorization requests and responses, exchanged as EDI between payers and providers. Da Vinci PAS is the FHIR implementation guide behind the CMS-0057-F Prior Authorization API: the same authorization conversation expressed as FHIR resources over REST, through the Claim/$submit and Claim/$inquire operations. Because the two carry equivalent business content, PA Bridge translates both into one canonical authorization record instead of running a FHIR gateway beside a separate X12 stack.
Prior authorization EDI integration connects a payer's utilization-management system to the X12 278 request/response transaction so authorization requests and responses move electronically instead of by fax or portal. Under CMS-0057-F, impacted payers must also operate a FHIR Prior Authorization API by January 1, 2027, so the practical pattern is a translation layer: providers call Da Vinci PAS endpoints while the UM system keeps speaking 278 over the connections it already has.
Request sandbox access to run a Da Vinci PAS round-trip against synthetic data, 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.