CMS-0057-F made FHIR the public-facing surface for Prior Authorization, but inside almost every US health plan, the back office still speaks X12. The 278 request and 275 attachment formats are deeply embedded in UM systems, EDI pipelines, and clearinghouse contracts. A FHIR ePA solution that ignores X12 forces the payer to rebuild every downstream integration. The seven tools below handle the X12 278 / 275 to FHIR round-trip with enough fidelity to ship in production. For more on payer-side FHIR, the broader picture lives across this site.
1. Edifecs ePA Stack
Edifecs has the longest X12 lineage of any ePA vendor and built its FHIR ePA layer directly on top of the existing 278 / 275 engines. The round-trip is bidirectional and well-tested. The CRD and DTR pieces sit alongside, often integrated through Edifecs Smart Trading. Best fit for payers whose UM and clearinghouse already run on Edifecs.
2. Rhapsody (Lyniate) Integration Engine
Rhapsody handles X12 at a primitive level and added FHIR ePA support through a combination of native filters and Da Vinci-conformant adapters. The round-trip is configurable rather than baked in, which is a strength for payers that want control and a weakness for teams that want pre-shipped behavior. Rhapsody licenses tend to follow legacy HL7 v2 footprints.
3. PilotFish HealthRecon
PilotFish built HealthRecon around integration patterns rather than specific vendor stacks. The X12 to FHIR conversion is rule-driven and observable, which makes audit work straightforward. PilotFish does not ship the full Da Vinci CRD / DTR / PAS triad itself; it pairs with a separate FHIR endpoint provider for the application layer.
4. InterSystems IRIS for Health
InterSystems IRIS handles X12 through its Ensemble lineage and exposes the FHIR ePA endpoints through the IRIS for Health interoperability platform. The single-stack story (X12, HL7 v2, FHIR, and the data warehouse all in one) is the strongest selling point. The trade-off is enterprise pricing and a longer learning curve for teams that have not used IRIS before.
5. MuleSoft Healthcare Accelerator
MuleSoft Healthcare Accelerator (Salesforce) ships X12 connectors as part of the broader Anypoint integration platform. The FHIR ePA pieces use the same connectors and flow logic. Best fit for payers that already run Anypoint for non-healthcare integrations; less obvious value if MuleSoft would be a fresh investment.
6. Smile Digital Health (with X12 Connector)
Smile Digital Health is FHIR-native at the core and handles the X12 round-trip through a partner connector rather than a built-in module. The setup works cleanly in practice, with the FHIR Bundle becoming the canonical representation and X12 generated on the fly when the back-office UM system requires it. The honest framing is that Smile is a strong FHIR platform plus a competent X12 integration, not an X12-native engine.
7. 1upHealth (via Partner Conversion Layer)
1upHealth follows a similar pattern to Smile, with the FHIR ePA modules first-class and X12 handled by a partner conversion layer. The developer ergonomics are the best in the group, which matters for payers building custom workflows on top of the standard Da Vinci endpoints. PMPM pricing scales with member count and tends to be the cleanest choice for small to mid-size plans.
How to Pick Based on Your X12 Estate
The shortlist resolves quickly when you map your existing X12 estate. Payers with a heavy Edifecs or PilotFish footprint stay with their incumbent and add the FHIR layer on top. Payers running Rhapsody for HL7 v2 typically extend Rhapsody. Payers without a settled integration engine and with a 3-6 month timeline are the ones that benefit most from FHIR-native platforms with partner X12 layers.
For the strategic question of whether X12 should stay primary or yield to Da Vinci PAS as the new system of record, the Da Vinci PAS vs Legacy X12 278 comparison lays out the decision. For real-time decision flow back into Patient Access, the FHIR Subscription engines for real-time Prior Auth decisions covers the notification path.