XDS Telecom uses non-spec compliant Long Datatype

[svenhaag]

The following Telecom parts

• countryCode
• areaCityCode
• localNumber
• extension

are defined as Long which does not properly reflect the standard.

Depending on the HL7v2 version the correct data type is either NM (Numeric) or SNM (String Numeric).
Between HL7v2 2.3 and 2.6 the type is NM. Starting with 2.7 the type changed to SNM, see https://www.hl7.eu/HL7v2x/v27/hl7v27typXTN.htm for the parts 5-8:

• Country Code
• Area/City Code
• Local Number
• Extension

The HL7 data types not only allow digits but also a set of special characters like +, / and leading zeros!

[unixoid]

Hello @svenhaag

Table 4.2.3.1.7-2 "Data Types" in ITI TF-3 mandates the usage of HL7 version 2.5 -- therefore, the only possible data type is NM.

Best regards
Dmytro

[Thopap]

The examples in TF-3 are definitly misleading (and wrong).

There was a change proposal (CP-977) in 2017/2018 to improve the XTN definition:
https://docs.google.com/document/d/1ZGQMbiq2uj9Zsb-JXVp9glUoEXclX-n8

The strange thing here: The CP is final text, but it seems to be still missing in the spec.

[svenhaag]

Thanks Thomas for pointing that out.
If I read that correctly, the CP also points out that only numbers shall be used?

As far as the NM type goes the usage of Long is wrong. A (regex checked) String shall be used instead.

• chars 0-9
• length 1-16
• optional leading sign + or -
• decimal point
• contains at least one digit to the left of the decimal point, i.e. .1 is invalid

They also recommend truncation, but I would not do that. In my opinion, leading zeros should not be truncated at all.

[Thopap]

Hello Sven,

the CP add the usage of XTN-12 to express a phone numbers in any format (e.g. the recommended ITU E.123 notation). So when implementing this, a String field must be added to IPF. I have created an issue on the IHE github account to report this: IHE/publications#628

For existing fields (XTN-5,6,7,8), you are right, the implementation in IPF might be slightly too strict.

[unixoid]

As my own phone number has a leading zero in the local number part (XTN.7), I had to do something.
Please feel free to close this issue if the solution is Ok for you.

[svenhaag]

Which solution? What did you have to do?

I still intend to provide a merge request with a fix.
My proposal would be, to provide a validator type to the class, containing e.g.:

• Lenient
• Strict IHE
• Strict HL7

Depending on that type the corresponding validation would happen.
The validation type could be provided via configuration.

[unixoid]

See my commit above. There are new getters and setters that use Strings instead of Longs. In this way, leading zeros and "+" signs are not lost.

[svenhaag]

Thanks a lot! Can we backport this to 4.x too?

[unixoid]

x = ?

[svenhaag]

I suppose as this is a new feature it should be 4.9.0 @ohr?