· Aug 18, 2016

Is there something I'm missing on these data types in the HL7 Schema definition?

Given the following data type:


<DataType name='TN' description='telephone number'>
    <DataSubType piece='1' description='telephone number'/>


What is the point in setting a SegmentSubStructure's datatype to "TN" instead of "ST"?

Discussion (4)0
Log in or sign up to continue

I think that validating data types across the board in Ensemble is only useful in a few specialist situations, such as building an HL7 clearing house. It is expensive and often gets in the way of what you really want to achieve.

What downstream applications will successfully handle in messages is often very different to the published standard and most people will focus on validating particular fields that are important to their environment rather than adherence to the standard.

In the case of TN the early HL7 schemas defined it as a string, but added no structure or length restrictions so it added no value other than documenting for applications that this field was expected to be a phone number. It seems to have gone from HL7 2.5 and later.


And just to provide some context to what I'm trying to accomplish, we have had numerous instances in the past where a customer started sending data we did not expect.  In some cases, these changes technically met the schema and in other cases it violated it but we never had our productions set up to alert on validation exceptions.  As a result of a few of these, I am currently doing a complete ADT remediation process where I am tightening the schemas and enabling alerting for  validations on all namespaces.

Is this not recommended? Do you have other input or advice?