ISO/HL7 27932:2009 (2012) — HL7 v3 Data Types Specification

1. Overview of ISO/HL7 27932:2009 (2012)

ISO/HL7 27932:2009, reaffirmed in 2012, specifies the data types used in HL7 Version 3 messages. This standard defines a comprehensive type system that ensures semantic consistency across all HL7 V3 interactions. The data types specification is a critical companion to the messaging standard (ISO/HL7 27931), providing the fundamental building blocks for all clinical data representation. It covers everything from basic text and numeric types to complex constructs such as precise healthcare timestamps, coded vocabulary references, and multi-language text blocks. The specification defines the XML Schema representation for each data type, enabling automated validation of message content against type constraints.

The data types specification draws heavily on the HL7 V3 Abstract Data Types specification (HL7 ADT) and extends it with concrete XML Schema implementations. The standard distinguishes between “data types” (the abstract semantic model) and “data type implementations” (the specific XML, and potentially other, representations). This separation allows the same clinical semantics to be encoded in different concrete syntaxes, a design principle that later influenced the FHIR standard’s approach to multiple serialization formats.

2. Data Type Taxonomy and Key Types

2.1 Fundamental Data Types

The standard organizes data types into a formal hierarchy rooted in the ANY abstract type. Fundamental types include: BL (Boolean) with three-valued logic (true, false, and null); INT (Integer) with arbitrary precision; REAL (Real number) with configurable precision; ST (String, unordered text); and CV (Coded Value) for concept representations that include both a coded identifier and human-readable display text. The CS (Coded Simple) type provides a compact representation for codes where only the code value is needed without the display name.

2.2 Healthcare-Specific Semantic Types

Several data types in ISO/HL7 27932 are uniquely designed for healthcare semantics. The IVL (Interval of Timestamps) type represents a time interval with low and high boundaries, essential for representing medication administration periods or hospitalization durations. The RTO (Ratio) type represents a ratio of two quantities, critical for representing concentrations (e.g., 5 mg/mL) and rates (e.g., 100 mL/hour). The PIVL (Periodic Interval of Time) type models recurring time patterns for scheduled events like “every 8 hours” or “every Monday at 9 AM,” directly supporting clinical dosing schedules.

2.3 Collection and Distribution Types

The standard defines collection types including SET (unordered, no duplicates), LIST (ordered, allows duplicates), BAG (unordered, allows duplicates), and DSET (ordered, no duplicates, with distinct semantics). For representing probability distributions, the standard provides BAG for simple collections and HIST for histogram data. These collection types are particularly important in laboratory and public health contexts where multiple observations or specimens must be transmitted as a cohesive unit.

3. Engineering Insights and Practical Implementation

3.1 TS Timestamp Precision Handling

The TS (Point in Time) data type supports configurable precision from year down to sub-second. A timestamp with year precision (e.g., 2024) is semantically distinct from one with full date-time precision (e.g., 20241115143015.1234+0800). Engineers must carefully manage precision expectations in message processing — comparing a year-precision date of birth with a day-precision admission date requires different handling than comparing two day-precision timestamps. The standard specifies that precision is indicated by the number of digits provided, not by explicit precision qualifiers.

3.2 Null Flavor Semantics

ISO/HL7 27932 defines a sophisticated null flavor mechanism that goes far beyond simple null values. The standard specifies multiple null flavors including: NI (No Information), NA (Not Applicable), UNK (Unknown), ASKU (Asked But Unknown), NAV (Not Available), and MSK (Masked). Each null flavor carries distinct semantics that affect downstream processing. For example, a blood pressure reading with MSK flavor indicates that the value exists but is being withheld for privacy reasons, while NA indicates that the concept is not relevant to the patient. This granular null handling enables clinical decision support systems to reason appropriately about missing data.

3.3 Coded Value Type Resolution and Vocabulary Management

The CD (Concept Descriptor) type allows qualifiers to refine the meaning of coded values, enabling post-coordination of clinical concepts. For example, a SNOMED CT code for “fracture” can be qualified with “site = femur” and “severity = comminuted” to create a compound clinical concept without requiring a pre-coordinated code for every possible combination. Managing these qualified codes in terminology servers requires careful indexing strategy, as the semantic equivalence of two qualified codes depends on the full qualification chain, not just the base code.

4. Frequently Asked Questions