HL7 CNN Data Type: Composite ID Number and Name Simplified

The CNN (Composite ID Number and Name Simplified) data type was introduced in HL7 v2.4 as a lighter-weight cousin of XCN. Like XCN, it pairs a person's identifier with a structured name (family, given, middle, suffix, prefix, degree), but it flattens the assigning authority into three plain components instead of nesting an HD sub-structure. The flagship use is inside other composite data types - most notably as the .1 Name component of NDL (Name with Date and Location) - and in profiles where the full 25-component XCN was overkill (CTI-3 Sponsor Study Identifier, plus ABS, BTS, and ROL in older profiles).

Purpose

CNN exists because not every person-bearing field needs the full machinery of XCN. The 25 components of XCN - name type code, check digit, check-digit scheme, assigning facility, name representation, name context, validity range, assembly order, effective/expiration dates, professional suffix, assigning jurisdiction, assigning agency, security check, security check scheme - are far more than many use cases need. CNN trims the surface to 11 components: an ID, a name, a degree, a source-table code, and a three-part flattened assigning authority. The flattening matters: where XCN.9 is a single HD whose sub-components use & as the separator, CNN.9 / CNN.10 / CNN.11 are three sibling components separated by the normal ^. That choice removes the sub-component delimiter from CNN entirely.

Components

Source: HAPI HL7v2 v2.8.1 javadoc (CNN). Length is not published in v2.8.1 javadocs (-).

Most-used components

• CNN.1 ID Number - the practitioner's directory key; the one component that drives downstream resolution.
• CNN.2 Family Name - surname (plain ST, not FN).
• CNN.3 Given Name - first name.
• CNN.7 Degree - professional credential (MD, RN, PA-C). Unlike XCN, CNN never had this withdrawn.
• CNN.9 / CNN.10 / CNN.11 - the flattened assigning authority triple; populated together when the identifier needs to be disambiguated across networks.

Where it's used

• CTI-3 Sponsor Study Identifier - the sponsor's principal investigator reference in clinical-trial profiles.
• ABS, BTS, ROL in older v2.4-era profiles where the full XCN was considered overkill for the role-holder field.
• As the .1 Name component of NDL (Name with Date and Location) - every OBR-32/33/34/35 v2.5+ message uses CNN inside its NDL.
• Custom Z-segments in trial-management and research workflows that needed a person reference but did not want to take on XCN's full structure.

In all of these, CNN typically does not repeat - it stands alone or is held inside a single NDL slot.

Version differences

• v2.4 - CNN introduced as a simplified alternative to XCN; 11 components from the start.
• v2.5 - No structural changes. NDL retypes its .1 Name component to CNN.
• v2.6 / v2.7 - No new CNN components added. CNN deliberately remained frozen as the "simple" alternative while XCN accreted security and validity-range fields.
• v2.8 / v2.8.1 - No structural changes; HAPI v2.8.1 javadoc shows the same 11 components.

Common mistakes

• Treating CNN.2 as FN. CNN.2 is plain ST, so there are no FN sub-components - a compound surname like "de la Cruz" must be sent as a single ST value. Senders that emit de la&de la&Cruz inside CNN.2 produce a corrupted family name.
• Using & inside CNN.9 / CNN.10 / CNN.11. The assigning authority is flattened in CNN, not nested. The three pieces sit at the field level separated by ^, not at the sub-component level separated by &.
• Substituting XCN for CNN. Some profiles strictly type a slot as CNN; sending a full 25-component XCN value into it overflows the schema and discards components past CNN.11.
• Omitting CNN.9 / CNN.10 / CNN.11 on cross-network messages. Without the flattened authority triple, the same 99812 can refer to two different clinicians at two different sites.
• Putting the degree text in CNN.6 (prefix) instead of CNN.7. "MD" belongs in CNN.7 Degree; "DR" belongs in CNN.6 Prefix. They are not interchangeable.

Examples

Minimal value

99812^SMITH^JANE

Multi-component value

99812^SMITH^JANE^L^^DR^MD

Fully populated value

99812^SMITH^JANE^L^MD^DR^MD^L^MERCY^2.16.840.1.113883.19.5^ISO

Annotated breakdown

99812                             CNN.1   ID Number
^SMITH                            CNN.2   Family Name (ST - plain string, not FN)
^JANE                             CNN.3   Given Name
^L                                CNN.4   Second Given (initial)
^MD                               CNN.5   Suffix
^DR                               CNN.6   Prefix
^MD                               CNN.7   Degree (IS)
^L                                CNN.8   Source Table (IS HL70297)
^MERCY                            CNN.9   Assigning Authority Namespace ID (IS HL70363)
^2.16.840.1.113883.19.5           CNN.10  Assigning Authority Universal ID (ST)
^ISO                              CNN.11  Assigning Authority Universal ID Type (ID HL70301)

In-context excerpt - CTI-3 Sponsor Study Identifier

CTI|TRIAL-2026-OCN-014|Phase 2 Oncology|99812^SMITH^JANE^L^^DR^MD^L^MERCY^2.16.840.1.113883.19.5^ISO

Common pitfall snippet

99812^SMITH^JANE^L^^DR^^^MERCY&2.16.840.1.113883.19.5&ISO

The sender treated the assigning authority as nested HD (the XCN convention) using & separators inside a single CNN.9. A strict parser sees one component containing literal ampersands and never populates CNN.10 or CNN.11.

FHIR mapping

The v2-to-FHIR IG publishes CNN → Practitioner as the primary mapping. Because CNN's assigning authority is flattened, the receiving FHIR Practitioner.identifier.assigner reference must be assembled from three sibling components rather than parsed from a single HD sub-structure.

Engine considerations

• No sub-component delimiter in CNN: CNN was deliberately designed without nested HDs. Engines that expect & somewhere inside CNN are wrong by spec - the only delimiter inside CNN is ^.
• Flat vs nested assigning authority: When converting between CNN and XCN, an engine must (a) split CNN.9 / CNN.10 / CNN.11 into XCN.9's HD sub-components on upgrade, and (b) collapse XCN.9's HD sub-components into three flat siblings on downgrade. Round-tripping a CNN through an XCN-only intermediate model loses the flatness contract.
• Family name is ST, not FN: An engine that strongly types every person-name family slot as FN cannot represent compound surnames in CNN without overflowing into other components. The string is stored as-is.
• Source Table (CNN.8) was never widened: Unlike XCN.8 which became CWE in v2.7+, CNN.8 remains IS in v2.8.1. Engines that fold both into a CWE model must remember that CNN's column is still IS on the wire.
• No security check, no validity range: CNN has no XCN.19/20 effective/expiration dates, no XCN.24/25 security check. Engines that expect those fields must obtain them out-of-band when serializing CNN.

How Vorro parses and produces CNN

On inbound, Vorro materializes CNN as a Practitioner using the same internal directory it uses for XCN, but the identifier triple is built from (CNN.9, CNN.10, CNN.11) as three flat strings rather than from a nested HD. CNN.2 is stored as a plain string; we do not attempt to split compound surnames into FN-like sub-parts because the wire form does not carry that structure.

On outbound, Vorro always emits CNN.1 with a populated identifier (we refuse to send a CNN without one). When the upstream model carries an HD-shaped assigning authority, we flatten it into CNN.9 / CNN.10 / CNN.11 and emit a debug breadcrumb noting the downgrade so audit consumers can see the conversion. The degree value is always emitted in CNN.7; we never overload CNN.6 prefix with credentials.

Related pages

• XCN data type - Extended Composite ID Number and Name for Persons
• XPN data type - Extended Person Name
• HD data type - Hierarchic Designator

Sources

• HAPI HL7v2 v2.8.1 javadoc - CNN
• HAPI HL7v2 v2.8.1 apidocs index
• HL7 v2 product brief
• v2-to-FHIR ConceptMap - CNN to Practitioner