Optionality, Cardinality, and Loose Conformance

The standard tells you what may appear, not what must

A message type in HL7 v2 defines an ordered set of segments, and each segment defines a sequence of fields. But knowing which segments and fields are allowed is only half the picture. For each one, the standard also says whether a sender is obliged to populate it, permitted to populate it, or forbidden from populating it. This property is called usage (or optionality), and it is the single most important reason two systems can both pass for “HL7 v2 compliant” and still fail to exchange data ¹.

Every field and every segment carries a usage code. The base standard uses a small vocabulary:

Code	Name	Meaning for the sender
R	Required	Must always be populated with a valid value.
O	Optional	May be populated; the sender decides case by case.
C	Conditional	Required or not depending on a stated rule (e.g., another field’s value).
X	Not supported	Must not be sent; receivers should ignore it if present.

Conformance profiles (next lesson) extend this vocabulary with RE — required but may be empty: the element must be supported and sent when data is available, but may be omitted when it is not. Older material also carries legacy B (retained for backward compatibility) and W (withdrawn) markers.

The decisive fact about the base standard is its bias: the overwhelming majority of fields are marked O, Optional ¹. The specification is written to describe everything a message could carry across the whole of healthcare, so it leaves almost every individual element to the discretion of the implementer. Only a thin spine of elements is genuinely Required.

Cardinality: how many times something may appear

Usage answers “must this appear at all?” Cardinality answers “how many times may it appear?” It is written as a min..max pair:

• [0..1] — appears zero or one time (optional, non-repeating).
• [1..1] — appears exactly once (required, non-repeating).
• [1..*] — appears at least once, no upper bound (required, repeating).
• [0..*] — appears any number of times, including none.

The asterisk means “unbounded.” Cardinality applies to repeating fields (a patient may have several phone numbers) and to repeating segments (an order message may carry many result segments). A minimum of 0 is just another way of saying the element is optional; a minimum of 1 makes it required. So usage and cardinality together describe the full freedom each element has, and in the base standard that freedom is wide ².

Why “compliant” does not mean “interoperable”

Here is the trap. Suppose System A and System B both implement the same message type, and both validate cleanly against the published standard. System A sends patient demographics but, because the field is Optional, never includes the patient’s primary insurance plan ID. System B, downstream, treats that same field as essential for billing and rejects or mishandles any message without it.

Neither system has broken the standard. System A is allowed to omit an Optional field; System B is allowed to want it. Both are “HL7 v2 compliant.” Yet they cannot interoperate, because compliance was measured against a specification so permissive that it constrains almost nothing. This is what practitioners call loose conformance: conforming to the abstract standard guarantees only that your messages are well-formed, not that they carry the data your partner needs ¹.

The problem multiplies with every Optional element. Two implementers reading the same document can make hundreds of independent, locally reasonable choices about what to send, what to require, and how many repetitions to expect. Each choice is legal in isolation; in combination they produce two systems speaking dialects of the same language that do not quite line up.

Closing the gap: agreements, profiles, and implementation guides

Because the base standard cannot enforce a meeting of the minds, the industry’s first answer was the site-to-site interface agreement: a document negotiated between two trading partners spelling out exactly which Optional fields will be sent, which are required at the receiver, and how each is to be coded. Every new connection meant another bilateral negotiation, which scaled poorly as interfaces multiplied ¹.

The durable answer was to formalize those agreements as reusable artifacts: message profiles and implementation guides that constrain the base standard for a specific use case. Profiling means taking a message and tightening its optionality and cardinality — promoting an Optional field to Required, narrowing [0..*] to [1..1], marking unused segments as Not supported, and fixing the allowed code sets ². A profile is still legal HL7 v2; it simply removes the slack that made loose conformance ambiguous. (The next lesson examines how profiles are written and validated.)

The practical lesson

Treat “HL7 v2 compliant” as a necessary but not sufficient condition. Compliance tells you a message is structurally valid; it says almost nothing about whether two systems will successfully exchange the data they actually need. Real interoperability comes from constraining optionality — agreeing, explicitly and in writing, which of the standard’s many “maybes” become “musts” for the interface at hand ¹. The standard supplies the vocabulary and grammar; a profile supplies the shared contract.