The 837P claim is the electronic professional claim that every Minnesota home and community-based services (HCBS) agency sends to Minnesota Health Care Programs (MHCP) and to managed care organizations (MCOs). It is defined by X12 standard 005010X222A1, required in Minnesota by Minn. Stat. § 62J.536, and constrained by the Minnesota Uniform Companion Guide (MUCG) that the Minnesota Department of Health (MDH) adopts as a rule.
A biller does not need to read the whole X12 implementation guide. The fields that fail are a short list: the billing and rendering provider identifiers, the subscriber, the CLM segment, the service line code, modifiers, units, and dates, and the authorization reference. This guide covers those fields, the Minnesota companion guide, rejections versus denials, clearinghouse versus direct submission, and a pre-submission checklist, as of September 2026 (MUCG version 18.0).
For how the file is uploaded and acknowledged, see the MN-ITS guide. For what the payer says when a line does not pay, see the MHCP claim denials guide.
Which rules govern the 837P in Minnesota
| Rule | What it does |
|---|---|
| X12 005010X222A1 (TR3) | The national implementation guide for the professional claim; defines every loop, segment, and element |
| Minn. Stat. § 62J.536 | Requires Minnesota providers, group purchasers, and clearinghouses to exchange claims electronically under a single uniform companion guide |
| Minnesota Uniform Companion Guide v18.0 for the 837P | MDH rule adopted under § 62J.61 in consultation with the Minnesota Administrative Uniformity Committee (AUC); adds Minnesota-specific notes on identifiers, adjustments, attachments, and coding |
| MHCP MN-ITS 837P user guides | DHS instructions for direct data entry, listing the MN-ITS fields required for each service type |
| MHCP Provider Manual billing policy | Timely filing, replacement and void rules, remittance formats |
The companion guide itself makes one point that every biller should absorb: compliance with the guide does not mean a claim will be paid. It governs the format, not the payer's coverage or authorization rules.
The 837P structure a biller needs to know
An 837P is organized in loops. Each loop has segments, and each segment has elements. The table maps the loops that carry the fields Minnesota HCBS claims most often get wrong.
| Loop | What it carries | Fields that fail |
|---|---|---|
| 2010AA Billing provider | Organization name, NPI (NM109), address, TIN as a secondary identifier, taxonomy in the PRV segment when the payer needs it | NPI not enrolled or not affiliated; address that does not match the enrollment record |
| 2010BB Payer | Payer name and ID; for atypical billing providers, the G2 secondary identifier (UMPI) | Wrong payer ID for the MCO; missing G2 for an atypical provider |
| 2010BA Subscriber | MHCP member ID, name, date of birth | Member ID or name that does not match the 271 |
| 2300 Claim | CLM01 patient account number, CLM02 total charge, CLM05-1 place of service, CLM05-3 frequency code; HI diagnosis codes; REFF8 payer claim number; REFG1 prior authorization; CLM20 delay reason | Frequency code 1 on a correction that should be a 7; diagnosis not supported by the record; missing authorization reference |
| 2310B Rendering provider | The individual who delivered the service, NPI or G2 UMPI | Worker not enrolled or not affiliated on the date of service |
| 2400 Service line | SV1 with the HCPCS code (HC qualifier), up to four modifiers, line charge, unit qualifier UN, unit count, diagnosis pointers; DTP472 date of service; line-level REFG1 when the authorization is line specific | Wrong modifier, units above documented time, date outside the authorization span, pointer to a diagnosis not on the claim |
Under the MUCG, if the provider is a health care provider as defined under federal standards, the only valid identifier is the NPI, except that the billing loop also requires the TIN. An atypical provider, one that does not meet the federal definition and cannot get an NPI, uses the TIN as the primary identifier and a payer-assigned identifier under qualifier G2. For MHCP that identifier is the 10-digit unique Minnesota provider identifier (UMPI), assigned at enrollment. DHS lists individual personal care assistants among the atypical providers, which is why a CFSS or PCA service line carries the worker's UMPI or NPI as the rendering provider; the CFSS billing guide covers that rule.
The CLM segment
CLM05-3 is the claim frequency type code. Code 1 is an original claim, 7 a replacement, and 8 a void. The MUCG requires an adjustment to be submitted with the appropriate value in CLM05-3 and, if the payer assigned a claim number, that number in Loop 2300 REF02 with qualifier F8. A replacement replaces the entire claim, so every line goes back on it. If CLM20 delay reason code 11 (other) is used, the MUCG requires additional documentation through the NTE or PWK segment. The mechanics and timing are in the timely filing and replacement claims guide.
The service line
The SV1 segment is where the money is. SV101 carries the HC qualifier and the HCPCS or CPT code with up to four modifiers; SV102 the line charge; SV103 the unit qualifier UN; SV104 the units; SV107 the diagnosis pointers back to the HI segment. The DTP segment with qualifier 472 carries the date of service. Units must equal what the note supports: H2017 in 15-minute units for ARMHS, T1019 in 15-minute units for CFSS, EIDBI CPT codes with the UB modifier. Place of service belongs in CLM05-1 and must agree with the note; telehealth claims carry the place of service and modifier the MHCP telehealth policy specifies.
The authorization reference
The 837P carries a prior authorization number in REFG1 and a referral number in REF9F, at the claim level in Loop 2300 or at the line level in Loop 2400. MHCP's MMIS matches waiver, home care, and CFSS claims against the service agreement by member, provider, procedure code, dates, and units, and the MN-ITS 837P claim information screen shows the authorization number field. Whether MHCP requires the number for your service is stated in the MN-ITS 837P user guide for that service; the service agreements and prior authorization guide explains how the authorization is created and how its units travel to the claim.
Rejections versus denials
A claim can fail at four points, and the fix depends on which one.
| Stage | Response | What it means | What to do |
|---|---|---|---|
| Interchange | TA1 | The file envelope is invalid; MHCP rejects with TA1 for invalid interchange content | Fix the envelope and resubmit the whole file |
| Transaction set | 999 (accepted or rejected) | The file does or does not meet X12 5010 and companion guide rules, such as uppercase and case-sensitive qualifier values | Fix the syntax error the 999 identifies and resubmit the transaction set |
| Pre-adjudication | 277CA | The payer accepted or rejected individual claims into adjudication | Correct the rejected claims and resubmit them as new original claims |
| Adjudication | 835 with CARC and RARC | The claim was processed and paid, partly paid, or denied | Work the denial; correct with a replacement claim (frequency 7) or appeal |
The distinction matters for timely filing. A claim rejected on a TA1, 999, or 277CA was never received by the payer and does not count toward the 12-month MHCP window. Keep the acknowledgments with the batch; they prove when a claim reached the payer.
Audit tip: a rejection is a data problem, and a denial is usually a documentation, eligibility, or authorization problem. If the same rejection recurs across batches, fix the template or the provider record, not the individual claim. If the same denial recurs, fix the pre-claim check.
Clearinghouse versus direct submission
Direct submission means the agency's software produces the 837P file and uploads it to MN-ITS, or sends it by SFTP, and MHCP returns the 999 and remittance directly. It costs nothing, and the agency owns every acknowledgment. Its limit is that MN-ITS reaches only MHCP fee-for-service; each MCO has its own connection.
A clearinghouse takes one 837P file, applies its own edits, and routes claims to MHCP and to every MCO, at a cost, and adds a second set of acknowledgments to reconcile. Whichever route an agency chooses, the provider must keep its own MN-ITS access. DHS does not accept direct data entry from a clearinghouse, and a clearinghouse cannot run 270 eligibility or 276 claim status inquiries for the provider; the MHCP eligibility verification guide explains why those inquiries have to be run per date of service.
Pre-submission checklist for Minnesota HCBS 837P claims
Run this before every batch, in software if you can.
- Billing provider. NPI (or TIN plus G2 UMPI for an atypical provider) matches the MHCP enrollment record, and the enrollment is active on every date of service.
- Rendering provider. The individual's NPI or UMPI is enrolled and affiliated to the billing organization on the date of service.
- Subscriber. Member ID, name, and date of birth match the 271 for the date of service, and the 271 shows fee-for-service MHCP, not an MCO.
- Authorization. An approved service agreement or prior authorization covers the code, the dates, and enough remaining units; the number is in REF*G1 where the MN-ITS user guide requires it.
- Service line. HCPCS or CPT code and modifiers match the MHCP billing grid for the service and provider type; units equal the documented start and stop time; the date of service is inside the authorization span.
- Place of service and diagnosis. CLM05-1 matches the note; every diagnosis pointer points to a code in the HI segment that the assessment supports.
- Frequency code. Code 1 for a new claim; code 7 with REF*F8 for a correction to a paid claim; code 8 only to void.
- EVV. For PCA and CFSS lines, the visit is verified in the HHAeXchange aggregator and matches the date, worker, and units.
- Duplicates. No accepted claim already exists for the same member, service, and date unless this is a replacement.
How Trustora helps
Trustora builds the 837P from the documented service. The billing provider, rendering provider, member, code, modifiers, units, place of service, and date of service come from the enrollment record, the progress note or EVV visit, and the authorization, so the claim cannot disagree with the record. The compliance engine's pre-claim gate runs the checklist above before a claim can be released, and holds the ones that fail.
Batches go to MN-ITS or a clearinghouse, the 999 and 277CA acknowledgments are stored with the batch, and the 835 is posted back to each line with its reason and remark codes. Corrections open as replacement claims with frequency code 7 and the original payer claim number carried forward. The platform covers ARMHS, 245D, PCA/CFSS, EIDBI, and adult day services in one system; see the claims features for the full lifecycle.