Version 2 of the HL7 standard is the version that is currently in common use. It has been designed to always be backward compatible. For example, version 2.6 of the standard is compatible with version 2.5. This ensures that existing applications that use the standard do not have to be constantly updated to match the evolving standard. Because these versions of the standard are backward compatible, they are often referred to as version 2.X of the HL7 standard.
Because version 2.X is backward compatible, the exact version number of the HL7 message is usually not important. What is often more important is how the vendor that is sending HL7 messages to you is populating the fields and segments defined in the standard.
For an example of backward compatibility in version 2.X of the HL7 standard, consider the Patient ID field in the PID segment. Early versions of HL7 declared the Patient ID to be just a simple, one-field identifier:
|PatientID|
In more recent versions, the Patient ID field has been modified to include more sub-fields. Examples of sub-fields that have been added include an identifier check digit, an assigning authority, and an identifier type code. To ensure backward compatibility, the sub-fields that have been added to the Patient ID field are optional.
When a field can contain several sub-fields that are optional, the message does not need to include delimiters if all of the fields are empty. For example,
For example,
|234324^^^|
is equivalent to:
|234324|
You only need to supply delimiters for empty fields if a later field contains a value:
|234324^^^X|
This helps to ensure backward compatibility: if new subfields are defined, they are assumed to be empty.
