Introducing Redix REST APIs

The Challenge

Healthcare organizations face a growing interoperability mandate. CMS-0057-F requires FHIR APIs by January 2027. Trading partners demand multiple data formats. Analytics teams need structured data from EDI transactions.

Building these conversion capabilities in-house means:

• 6-12 months of development time
• Deep expertise in X12, HL7, FHIR, and CDA specifications
• Ongoing maintenance as standards evolve
• Performance optimization to meet real-time SLAs

Every month spent building a converter is a month not spent shipping the features your users actually need.

One API Call

curl

curl -X POST "https://demo.redix.com/api/v2/hipaa-to-fhir/convert" \
  -H "X-API-Key: your-api-key" \
  -F "file=@claim.837"

That's it. The API returns a FHIR R4 Bundle. For the 278, Provenance records include the source X12 transaction identifiers for the converted bundle.

On the public demo, the shared demo key runs Redix sample payloads only; converting your own de-identified files uses a private evaluation key. Same endpoint either way.

Convert Between Any Format

HIPAA Transaction Coverage

All of these validate and convert to and from RMap; FHIR conversion covers all except the 820.

Audit-Ready Response Structure

Every 278-to-PAS bundle includes Provenance records with the source X12 transaction identifiers for the converted bundle: the assembler agent names the Redix engine and the implementation-guide version, and the source entity records the originating X12 transaction (ST and BHT). This is the actual response from the live demo:

{
  "status": "success",
  "fhir_bundle": {
    "resourceType": "Bundle",
    "type": "collection",
    "entry": [
      { "resource": { "resourceType": "Claim", "id": "..." } },
      { "resource": { "resourceType": "Patient", "id": "..." } },
      { "resource": {
          "resourceType": "Provenance",
          "recorded": "2026-06-19T13:00:00Z",
          "agent": [{
            "type": { "coding": [{
              "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
              "code": "assembler", "display": "Assembler"
            }]},
            "who": { "display": "Redix HIPAA-to-FHIR Engine (PAS 2.0.1)" }
          }],
          "entity": [{
            "role": "source",
            "what": { "identifier": {
              "system": "https://redix.com/fhir/NamingSystem/x12-source-transaction",
              "value": "ST*278*0001 (BHT-03: PADEMO001)"
            }}
          }]
      }}
    ]
  },
  "metadata": { "transaction_type": "278-request", "processing_time_ms": 62 },
  "warnings": []
}

Performance

Forward conversions run on a native C engine: no JVM warm-up and no garbage-collection pauses, which suits real-time gateways and serverless functions. Reverse FHIR to X12 and CDA to FHIR run through additional mapping layers. Actual latency depends on the input, mapping, hardware, and network, so measure it on your own files during evaluation.

Security and Data Handling

SDKs

Python

pip install redix-client

from redix_client import RedixClient
client = RedixClient(base_url="https://demo.redix.com", api_key="demo-key-12345")

Node.js

npm install redix-client

const { RedixClient } = require('redix-client');
const client = new RedixClient({ baseUrl: 'https://demo.redix.com', apiKey: 'demo-key-12345' });

Use Case: Real-Time Prior Authorization

Python

# Receive PAS FHIR request, convert to X12 278 for the backend
fhir_request = request.json

x12_result = client.post("/api/v2/fhir-to-hipaa/278-request", json=fhir_request)

# Send to the existing X12 278 / UM authorization system
x12_response = legacy_auth_system.process(x12_result['x12_output'])

# Convert the X12 278 response back to PAS FHIR
fhir_response = client.post("/api/v2/hipaa-to-fhir/278-response", files={"file": x12_response})

return fhir_response['fhir_bundle']

Simplified Path with RMap: If your team prefers not to manage raw X12 strings, use RMap as the intermediate format. RMap is a human-readable, comma-separated format designed to carry the data needed to produce X12 again - useful for debugging and audit trails.

Proven Across PAS Versions

Tested synthetic 278 request output (June 2026 run) passed validation against the CMS-listed PAS 2.0.1 and 2.1.0 profiles, with 2.2.1 as an additional validation target. Reverse PAS FHIR to X12 278 runs through the FHIR mapping layer and is scoped for private technical review or deployment evaluation, including validation of provider-generated PAS fixtures. This gives payers a practical path to put a compliant PAS FHIR front door on existing X12 278 / utilization-management systems without replacing them.

Summary

Stop building converters. Start shipping features.

Frequently Asked Questions