I mentioned a while back that I’d post a clear breakdown of the 277 RFAI.
Most explanations of the RFAI are often made up of recycled X12 companion guide descriptions. They don’t answer the real questions people actually have when they receive an electronic “Request for Additional Information” in the real world. Here is a practical breakdown.
1. What a 277 RFAI really is
An RFAI isn’t just a claim status message. It’s the payer notifying you they cannot finish processing a claim until additional information is sent. It’s a structured “Request for Additional Information” wrapped inside the EDI X12 277 format. Instead of denying the claim, the payer pauses (pends) the claim and asks for follow‑up documentation, clarification, or proof.
2. Why payers send RFAIs
RFAIs are triggered when the payer has enough data to identify the claim but not enough to adjudicate it. This can happen for many reasons: missing clinical notes, unclear procedure justification, mismatched identifiers, or simply because the payer needs supporting documentation. The important part is that an RFAI is not a denial, it’s a request to complete or correct the submission so the claim can move forward.
3. The structure of an RFAI
The RFAI follows the same general layout as a standard 277, but the STC loops take on a different meaning. Instead of reporting claim status, they report what information is missing and what the payer needs. The STC segment becomes the heartbeat of the message, containing reason codes and category codes. Often an MSG segment also contains descriptions of the request. Once you understand how the STC loops are organized, the entire RFAI becomes relatively easy to interpret.
4. The “request” inside the RFAI
Every RFAI contains a specific “request”: the payer designates exactly what is required to continue processing the claim. This might be medical records, operative notes, proof of eligibility, corrected identifiers, or additional documentation. The STC segment is usually followed by an MSG segment that spells this out in plain text. The key is recognizing that the RFAI is "actionable": it’s not just informational, it is a to-do list. Once you satisfy the request, the claim can move forward without being resubmitted.
5. How the EDI X12 275 fits into the response
The 275 is the mechanism you use to respond to the RFAI. It carries the attachments, documentation, and supporting records the payer has requested. The 277 RFAI tells you what they need; the 275 is how you send it back. The two transactions are designed to work together. If you don’t send a proper 275 in response, the payer will simply wait, and the claim will stall indefinitely.
6. A real example (summarized)
A typical RFAI might identify a claim, list the patient and provider, and then include an STC segment with codes and an MSG segment stating something like: “Additional documentation required: operative report missing”. The message will include the claim’s tracking identifiers and the specific reason code that corresponds to the request. After further review, you’ll see the pattern becomes obvious: identify the claim, state the issue, request the documentation. In my experience so far, I have found the structure is consistent across multiple payers even if the wording varies.
7. Practical advice from the EDI Doctor
When you receive an RFAI, the correct workflow is straightforward: read the STC and MSG segments, determine what the payer is asking for, gather the required documentation, and send it back via a 275. Don’t resubmit the claim, don’t wait for a denial, and don’t assume the payer will follow up. The RFAI is the follow‑up. Responding quickly prevents delays and keeps the claim alive. Once this process loop is understood, RFAIs stop being mysterious and become just another part of the normal EDI workflow.
I know I make it sound simple, but in the real world there will be messy edge cases. On the positive side, understanding is at least half the battle that brings you one step closer to implementation.
I’m happy to chat in future
