0

Some segments in HL7v2 can be repeating, but what if one of those repetitions is blank? Should the blank repetition be removed? Or should they remain?

For example, in the below extract PID.13 is a repeating field, but the first repetition is blank. It does not even contain "" (empty string).

PID|||A123456789^^^555^PI||Data^Test^^^Mr||19500101|M|||123 Test Road^Testington^^^AA1 2AA||~07778895566|||M|||||||||||||""|||
Amit Joshi
  • 15,448
  • 21
  • 77
  • 141
  • 1
    Empty/blank/null value is also a value. Blank repetitions should not be removed. Note that sequence of values will change if empty values are removed. – Amit Joshi Jul 28 '22 at 09:27
  • I would have thought that an empty value is still a value, but I can't seem to find anything in the specifications that clearly state this. Then again, the specifications also don't state the opposite. Perhaps it is one of those things that is open to interpretation? – user3778581 Jul 28 '22 at 15:48
  • You might want to edit your question because it isn't really about segments. Certain segments can repeat within certain message structures, but I think you're asking about field occurrence repetitions. – Nick Radov Jul 29 '22 at 17:09

2 Answers2

-1

The PID-13 field has been deprecated as of v2.7 and should no longer be used. Use PID-40 instead.

PID-13 is a special case because the first occurrence has a special meaning, so if there are multiple field repetitions then you shouldn't remove the first one even if it isn't populated. For other fields which don't have documented special cases, you can safely delete empty field occurrence without changing the meaning of the message.

Nick Radov
  • 401
  • 2
  • 7
-2

Please refer to this answer.

There are two things needs to be understood.

First:- Empty/blank/null value is also a value. Blank repetitions should not be removed.

Following is what specifications (2.3.2.4 Repetition Separator) say:

2.3.2.4 Repetition Separator.

The repetition separator is used in some data fields to separate multiple occurrences of a field. It is used only where specifically authorized in the descriptions of the relevant data fields. The character that represents the repetition separator is specified for each message as the second character in the Encoding Characters data field of the MSH segment. Absent other considerations it is recommended that all sending applications use '~' as the repetition separator. However, all applications are required to accept whatever character is included in the Message Header and use it to parse the message.

Yes; it does not clearly say anything about removing or keeping empty sub-components. Yes, it neither specifically say that empty value is also a value nor the opposite. I fail to find it in other parts of specifications as well.

To come to the conclusion, we need to move to second thing.

Second:- The sequence of repetition values may also be important. This sequence will change if empty values are removed. This may also change the meaning of the value.

Let us take an example of PID.13 you mentioned in the question.

This field contains the patient's personal phone numbers. All personal phone numbers for the patient are sent in the following sequence. The first sequence is considered the primary number (for backward compatibility). If the primary number is not sent, then a repeat delimiter is sent in the first sequence.

As you can see above, empty value for first sub component tells you that "there is no primary number available for patient". By removing empty value, you are actually putting "secondary number" in place of primary number which may be wrong depending on your use case or implementation.

Other example of PID.3:

This field contains the list of identifiers (one or more) used by the facility to uniquely identify a patient (e.g., medical record number, billing number, birth registry, national unique individual identifier, etc.).

As you can see, by removing empty values in-between changes the meaning of identifier.


I will still prefer clear reference from specifications, but based on what said above, I will avoid removing empty values.

Amit Joshi
  • 15,448
  • 21
  • 77
  • 141
  • 1
    The PID.13 example is an excellent use case. I had not considered backwards compatibility and despite the specification not clearly stating one way or the other, if you remove data then you are not being backwards compatible. – user3778581 Jul 29 '22 at 08:07
  • That isn't completely correct. HL7 v2 doesn't have a concept of "null" (older versions referred to the delete indicator as "null" but that terminology has been changed). Outside of a few limited fields where occurrence repetition number has significance for backwards compatibility, it is safe to delete blank (empty) repetitions. This is covered in Chapter 2. – Nick Radov Jul 29 '22 at 17:05