X12 278 UM Segment Guide: Fields, Format, and Testing Gotchas
UM sits right after the loop identifiers in a 278 request and does the actual work of telling the payer's UM system what's being asked for — get the category or the certification type wrong and the request doesn't bounce back with a clean error, it just gets reviewed as the wrong kind of request entirely.
UM (Health Care Services Review Information) is the segment in an X12 278 prior authorization request that specifies what category of review is being requested, whether it's an initial request or a follow-up, which service type is involved, and where the service will take place. Four elements do almost all of the work: UM01, UM02, UM03, and UM04.
The elements that actually matter in practice
Example
A 278 request for a health services review (HS), initial certification (I), service type 98 = professional office visit, at facility type 21 with admission type B, and Y indicating certification is being requested. Synthetic prior authorization data.
Where this trips people up
Test fixtures for the 278 tend to hardcode UM01 = HS and UM02 = I because that combination covers the "happy path" initial request, then never exercise a renewal (UM02 = R) or a revision (UM02 = S) against the same service type. Those code paths look identical at the segment level but route to completely different logic on the payer side, and a system that only ever generates initial requests never finds out its renewal handling is broken until a real extension request gets rejected.