Handling PAS traffic without changing your backend

You're already running production claims.

837 comes in.
You process it.
835 goes out.

That part works.

Now there's a new requirement on your plate: 278 real-time.

Maybe it's coming through Optum. Maybe direct. Maybe still being built.
Either way, it's not small. It touches response timing, backend data, and how requests and responses move through your system.

And it raises a question:

Do you need to build something new for this?

Same backend. New front door.

What you have today doesn't go away.

Whatever sits at the front—clearinghouse, network vendor, direct connection—that stays.

278 real-time just adds another way in.

A request comes in.
It still lands in the same place.
Your backend still does the same work.

Nothing inside your system changes.

You already use this pattern

Today, your system already works like this:

837 comes in → gets processed → 835 goes out.

Different formats at the edges.
Same processing in the middle.

You don't rewrite your backend for each format.
You let the format change at the boundary.

That's already how your system works. That's what RMap does in your existing 837 → 835 flow.

Even if you don't call it this, most systems already separate incoming formats from backend processing.

Same pattern for 278

278 real-time fits into that same flow.

A request comes in—maybe X12, maybe something else.
It gets processed the same way your system already processes requests.
A response comes out.

The difference is not what your backend does.
The difference is how the request enters and how the response leaves.

Today, your response might leave as X12 278.
Now it can also leave in a format expected by whoever is calling.

Same decision.
Same output.
Different door.

What this means in practice

You don't need to build a separate backend just to handle 278 real-time.

You don't need to duplicate your logic.

You extend the system you already run.

The work shifts to:

• how requests enter
• how responses exit

Not how decisions are made.

Why this matters

If you treat 278 real-time as a new system, it becomes a longer project:

• new backend paths
• duplicated logic
• more to maintain

If you treat it as an extension of what you already run, it stays inside your current scope.

Same system.
One more entry.
One more exit.

If this matches your situation, a short architecture call is the next step.

Redix has been used in production healthcare data processing for over 30 years across X12, HL7, and FHIR workflows.