State examples (Ohio MITS)

Outcome

You have a worked example of a real, in-production companion guide for one state Medicaid system (Ohio MITS) and can use it as a model for similar state guides — recognizing the patterns that recur across states.

Prerequisites

You have read 7.1 — The editor and 7.2 — Rule types & applicator. The Ohio MITS reference fixture lives at packages/x12/src/companion-guides/ohio-mits.test.ts and is the authoritative source for what is shown below.

What Ohio MITS is

The Ohio Medicaid Information Technology System (MITS) is the state's fiscal agent for Medicaid claims. Ohio MITS publishes a companion guide that adds a small set of state-specific overlays on top of the standard 837P / 837I / 270 / 271 implementation conventions. The platform's Ohio MITS guide encodes those overlays.

The full rule set (illustrative)

The shipped guide carries roughly two dozen rules. The categories:

Submitter / receiver overrides

rule_type: override
location: 1000B.NM1[NM101=40].NM103
value: "OHIO MEDICAID"
note: ISA-bound name should always read OHIO MEDICAID, not the partner display name.

rule_type: override
location: 1000B.NM1[NM101=40].NM109
value: "0617003"
note: Ohio MITS submitter ID, not the standard payer NPI.

Provider taxonomy validation

rule_type: validate
location: 2010AA.PRV[PRV01=BI].PRV03
expression: oneOf({PRV03}, [
  "171M00000X", "171R00000X", "183500000X",
  "175F00000X", "1041C0700X", "101200000X"
])
note: |
  Ohio's IDD waiver only accepts a fixed taxonomy set. If the billing
  provider's taxonomy is not in this list, the claim will be silently
  pended at MITS.

Service location rules

rule_type: append
location: 2310C.N4+1
segment: REF*LU*{serviceLocation.countyCode}~
note: |
  Ohio requires the service-location county FIPS code in a REF*LU. Without
  it, IDD waiver claims fail downstream verification.

Diagnosis pointer constraints

rule_type: validate
location: 2400.SV1.SV107
expression: and(
  match({SV107}, "^[0-9]+(:[0-9]+)*$"),
  len(split({SV107}, ":")) <= 4
)
note: |
  Ohio MITS rejects more than four diagnosis pointers per line, even when
  the implementation convention permits up to eight.

Required K3 segments

rule_type: append
location: 2300.HI[HI01:1=BK]+1
segment: K3*WAIVER:{program.waiverCode}*0~
note: |
  IDD waiver claims must carry the waiver code in a K3 immediately after
  the principal diagnosis HI. Other Ohio programs may require different K3s.

Tax ID handling for solo providers

rule_type: override
location: 2010AA.REF[REF01=EI].REF02
value: "{billingProvider.tin}"
condition: eq({billingProvider.organizationType}, "SOLO")
note: |
  Solo / sole-prop providers send TIN, not EIN. The override only applies
  when the billing provider is registered as SOLO.

Patterns that recur across states

Reading Ohio's guide alongside California, New York, or Texas highlights common themes:

Pattern	Why states do it
Submitter / receiver name override	The state's MMIS expects a fixed display name in 1000B regardless of how the partner is referenced upstream.
Taxonomy validation	Each state enforces its own approved-taxonomy list per program.
County / region appending	Most state Medicaid systems require a county FIPS or region code in a REF*LU.
Diagnosis pointer caps	States cap pointers below the 8 the standard allows (4 is typical).
Required K3 segments	Each state has its own K3 family — waiver code, program specifier, special-population indicator.
TIN vs EIN handling	Solo providers and group providers carry different REF qualifiers.

When onboarding a new state, scan its published guide for these six patterns first; they account for the vast majority of state-specific overlays.

Steps to onboard a new state from a published guide

1. Read the state's published companion guide PDF cover-to-cover. Note every section that says "differs from standard" or "in addition to the standard implementation."

2. Open /companion-guides → + New guide. Pick the trading partner and target transaction (837P / 837I / 270 / etc.).

3. Author rules pattern-by-pattern. Use the Ohio MITS fixture as the template. The pattern table above covers ~80% of any state guide.

4. Test against state-published sample transactions. Most states publish test cases; drop them into Live preview. The transformed output should match the state's expected examples.

5. Run Test connection on the trading partner (2.5 — Probe & test connection) to confirm the partner accepts the new envelope.

6. Activate with an effective_from aligned to the state's mandated go-live date.

Validation

Check	Expected
Live preview against the state's published sample matches	Yes — character-for-character on the diff.
Test connection succeeds end-to-end	Yes.
First production claim acknowledged with STC01 = A2:20	Yes — accepted into adjudication.
No payer-pended claims for the first week	Confirms taxonomy and K3 rules are correct.

Troubleshooting

Symptom	Cause	Fix
State pends claims silently	Validation rules are too lax	Tighten the validate expressions; the state's pending criteria are usually published in the guide PDF.
Live preview matches but production rejects	The state added a new rule between guide publication and your activation	Read the state's change log; clone and add the new rule.
K3 segments arrive in wrong order	append position selector wrong	Use a more-specific anchor (e.g. HI[HI01:1=BK]+1 rather than HI+1).
Provider taxonomy rejects but the operator believes it is valid	The taxonomy code is valid in NPPES but not on the state's approved list	The state's guide is final; change the billing provider's enrolled taxonomy with the state.

Next

2.1 — Onboard a new trading partner shows how guides bind to partners.