278 response — APPROVED / DENIED / PENDED

Outcome

The inbound 278 response is parsed, the HCR action code interpreted correctly, and the auth state in rcm-core flips to APPROVED, DENIED, or PENDED — with the certification number, certification effective window, and approved units / visits attached.

Prerequisites

The outbound 278 was sent (5.1 — 278 request). The partner has 278 inbound capability.

278 response anatomy

Source: packages/x12/src/inbound/services-review-278.ts. Same loop structure as the request, with an additional HCR segment carrying the payer's decision:

ISA → GS → ST*278 → BHT
  Loop 2000A — UMO (echoes request)
  Loop 2000B — Requester (echoes request)
  Loop 2000C — Subscriber (echoes request, sometimes with verified data)
  Loop 2000D — Dependent (echoes request)
  Loop 2000E — Patient Event
    UM (echoes request)
    HCR (action code — the headline decision)
    REF*BB (certification number, when approved)
    DTP*007 (certification effective begin)
    DTP*036 (certification effective end)
    HSD (approved quantity)
    [MSG] (free-text reason)
  Loop 2000F — Service (per-line decision)
    UM
    HCR (per-service action code)
    REF*BB (per-service cert number)
    HSD (approved per-service qty)
SE → GE → IEA

HCR — the action code

HCR01 carries the payer's decision. This is the single field that drives the auth status update.

HCR01	Meaning	Maps to status
A1	Certified in Total	APPROVED
A2	Certified — Partial	APPROVED (with reduced units)
A3	Not Certified	DENIED
A4	Pended	PENDED
A5	No Action	(informational only)
A6	Modified	APPROVED (with payer-changed parameters)
CT	Contact Payer	PENDED (manual followup needed)

HCR02 carries the certification number when the response is A1/A2/A6.

HCR03 carries the type of certification:

Code	Meaning
1	Certified
2	Conditional
3	Pre-certification
4	Continuing

HCR04 is the trace ID — useful for partner-side lookups.

Per-service vs per-event decisions

A 278 response can carry decisions at the 2000E patient-event level (one decision for the whole authorization) or at the 2000F service level (one decision per requested service line).

When both are present, the per-service decisions take precedence for each service; the patient-event decision serves as a default for any service line missing its own HCR.

The platform materializes the response by writing one service_authorization row per approved service, with the certification number from the most-specific HCR.

Pended state — what to do

A PENDED response means the payer needs more info. The 278 response typically carries MSG segments naming what they need:

Common pend reason	Resolution
Missing diagnosis detail	Update the auth's diagnosis list; resubmit with UM02 = S (revised).
Insufficient clinical justification	Attach clinical records via the rcm-app and resubmit.
Provider taxonomy not on file with payer	Ask the payer to update; resubmit.
Member coverage in question	Confirm eligibility (run a 270); resubmit.

A CT response (Contact Payer) means the payer wants a phone call — the 278 channel cannot resolve it. The platform marks the auth PENDED with a flag indicating manual followup.

Steps to materialize a response

The flow is automated; operator awareness for diagnosis only:

1. Inbound 278 arrives via the partner's transport.

2. parseServicesReview278() produces a structured response object.

3. The auth-request-consumer correlates the response back to the originating authorization_request via the trace number and / or the echoed REF segments.

4. AuthRequestService.recordResponse() writes the response onto the auth record:

   • Status flips per HCR01.
   • Approved units / visits / dates are written from HSD and DTP.
   • One service_authorization row per approved 2000F.
   • Audit trail captures the inbound transaction ID.

5. The clinician's view in rcm-app updates — the auth's status chip shows the new status with the certification number.

Validation

Check	Expected
Inbound 278 record appears	Yes.
correlation_id ties back to the original auth_request	Yes.
Auth status flips to APPROVED / DENIED / PENDED	Yes — within seconds of inbound parse.
Approved units in rcm-app match HSD02 from the response	Yes.
Certification number from HCR02 appears on the auth detail	Yes.

Troubleshooting

Symptom	Cause	Fix
Auth stays SUBMITTED despite 278 response arriving	Correlation failed (trace number missing or mismatched)	Open the inbound transaction; manually correlate via the admin endpoint, or refile with the right trace.
HCR01 = A2 but rcm-app shows full requested units	Per-service HSD not parsed; only event-level	Likely a parser bug for an unusual response shape — file an issue with the raw 278.
HCR01 = A4 (pended) but no MSG reason	Some payers omit MSG; pend reason is in their portal	Operator has to log into payer portal; mark the auth PENDED for manual followup.
Multiple cert numbers for one auth	Partner returned per-service certs	Each service_authorization row carries its own cert number; that is correct.

Next

5.3 — Manual-pending workflow