HL7 Table HL70098: Type of Agreement Code

HL70098 is one of the smallest tables in the v2 specification — three codes describing the contractual basis on which a payer agreement is being administered for a particular visit. It is carried in IN1-21 Type of Agreement Code, and it is rarely populated in modern profiles; most v2 traffic leaves the field empty and relies on payer-side configuration to determine the agreement basis.

Purpose

HL70098 distinguishes Maternity coverage (a separate agreement for OB services with its own benefits structure), Standard coverage (the default agreement on file), and Unified coverage (a single agreement that combines multiple lines of business — typically medical, dental, vision, and pharmacy under one administrative umbrella). The distinction mattered most in the 1990s, when payers commonly issued separate cards and separate claims streams for maternity benefits; modern coverage products generally bundle maternity into Standard or Unified, leaving HL70098 mostly historical.

The codes are single uppercase letters drawn from the IS data type. The table is user-defined, but in practice almost no sites extend it because the field itself is rarely populated.

Where it's used

IN1-21 Type of Agreement Code — the canonical and effectively only home of HL70098. Populated on IN1 segments when an ADT or DFT message carries a maternity-specific or unified-product coverage line.

Code list

Code	Display	Comment/Description
M	Maternity	Agreement covers maternity services under a distinct benefits structure.
S	Standard	The default agreement type — used when no special arrangement applies.
U	Unified	A single agreement that combines multiple lines of business (medical, dental, vision, pharmacy) under one administrative umbrella.

Code system OID

OID: 2.16.840.1.113883.18.30
Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0098

The OID resolves on the HL7 Terminology server and is the value Vorro emits in CWE.14 when a downstream profile demands OID-bound coded values for IN1-21. In practice the field is rarely populated, so the OID metadata rarely needs to travel.

HL7-defined vs user-defined

HL70098 is user-defined, but unlike most user-defined tables it is almost never extended. The three published codes have covered the realistic range of agreement types since the table was introduced, and modern payer products that need finer granularity (Medicare Advantage, Medicaid managed care, ACO arrangements) are surfaced through the payer-identification fields (IN1-3, IN1-35) rather than through IN1-21. Sites that do extend the table tend to add D for Dental-only or V for Vision-only carve-outs, but even those extensions are rare.

Version differences

v2.1 – v2.3 — Table first appeared with the three published codes.
v2.4 – v2.8.1 — Set stable at three codes. HL7 has not added further values; IN1-21 itself has been deprecated in some draft v2.9 documentation in favor of richer coverage-type modeling on the Coverage segment, but it remains active in v2.8.1.

Common mistakes

Confusing IN1-21 (Type of Agreement) with IN1-15 (Plan Type) or IN1-35 (Plan ID). IN1-21 describes the contractual basis; IN1-15 and IN1-35 describe the plan product. They answer different questions.
Sending the display word (Maternity) instead of the code (M). IN1-21 is IS-typed and expects the single character.
Populating IN1-21 for every visit regardless of agreement type. Most modern payer products are best represented as Standard (S) — or, more honestly, left empty so downstream systems do not infer a meaning that was not intended.
Inventing extensions that collide with future HL7 additions. The three-letter MAT, STD, UNI form is safer than single letters when extending.

Examples

A maternity-specific coverage line:

IN1|1|BCBS-PPO|BCBSMA|BLUE CROSS BLUE SHIELD OF MASSACHUSETTS||||GRP12345|EMPLOYER NAME||||20240101|20241231||DOE^JANE^A|SE|19850412|123 MAIN ST^^BOSTON^MA^02118|||1|||M

A standard medical agreement (the most common population):

IN1|1|AETNA-PPO|AETNA|AETNA LIFE INSURANCE||||GRP67890|EMPLOYER NAME||||20240101|20241231||DOE^JOHN^B|SE|19800101|456 OAK ST^^BOSTON^MA^02118|||1|||S

A unified product covering medical, dental, and vision under one agreement:

IN1|1|UNITED-UNIFIED|UHC|UNITEDHEALTHCARE||||GRP55555|EMPLOYER NAME||||20240101|20241231||DOE^JANE^A|SE|19850412|123 MAIN ST^^BOSTON^MA^02118|||1|||U

Mapping failure example — unknown agreement code:

IN1|1|BCBS-PPO|BCBSMA|BLUE CROSS BLUE SHIELD OF MASSACHUSETTS||||GRP12345|EMPLOYER NAME||||20240101|20241231||DOE^JANE^A|SE|19850412|123 MAIN ST^^BOSTON^MA^02118|||1|||X

X is not in the published HL70098 set. Because the table is user-defined, a conformant engine should not reject the message; it should route the value to the terminology curation queue, preserve it in the audit log, and forward it untouched so site-aware receivers can interpret any local extension.

FHIR mapping

HL70098 has no canonical FHIR ValueSet, and the v2-to-FHIR Implementation Guide does not publish a ConceptMap for it. The concept rarely surfaces in modern profiles, but when it does, implementers usually surface the value in one of two ways:

HL70098 intent	FHIR target
Coverage-product distinction (maternity vs standard)	`Coverage.type` CodeableConcept with a local code
Multi-line unified agreement	`Contract` resource with `Contract.type` describing the umbrella, plus `Contract.subType` for each line of business

Whichever target is chosen, the original HL70098 code should be preserved as an extension so the v2 outbound channel can restore IN1-21 verbatim. In most R4 profiles, however, IN1-21 simply does not round-trip at all because no downstream FHIR consumer asks for it.

Engine considerations

Sparse population — Engines should expect IN1-21 to be empty on the vast majority of messages and should not treat absence as an error.
Length — HL7-published codes are single uppercase letters. Site extensions are rare; do not hard-cap the field at one character because some sites use MAT/STD/UNI.
Case sensitivity — Codes are uppercase; normalize on ingest.
CWE upgrade path — In v2.7+ profiles IN1-21 may be transmitted as CWE rather than IS. Engines must handle both shapes and populate CWE.14 with the OID when the destination demands it.
Deprecation watch — IN1-21 is increasingly viewed as legacy. New integrations should consider whether the agreement distinction is actually consumed downstream before investing in populating it.

How Vorro handles HL70098

Vorro validates IN1-21 against the three HL7-published codes plus any site-registered extensions on ingest. Values that match are forwarded untouched. Values that fail validation are routed to the terminology curation queue, where they either resolve to a known code (and a remap rule is created) or pass through with a soft warning. Because the field is sparsely populated in real traffic, Vorro does not treat an empty IN1-21 as an integration defect.

On outbound, Vorro emits HL70098 as IS for v2.5 and earlier profiles and as CWE with CWE.14 populated for v2.7+ destinations that advertise OID-bound coded values. When the value originates from a site extension, CWE.12 carries the site OID rather than the HL7 base.

Sources

← Back to HL7 v2 Guide