This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

P514 fields with sequence

From HL7Wiki
Jump to navigation Jump to search


This is a page of type Category:InM Closed Action Items.

P514 Fields with Sequence based meaning


Sponsoring Person

 Joann Larson

Description

Update XCN, XPN, XAD, XTN and CWE fields currently having sequence-based meaning.

Disposition =

Accepted by INM on motion by __/__ (00-00-00)

Justification:

In the course of developing the US Realm v2.5.1 Lab Result Interoperability Specification, we discovered a number of fields in the chapter 3 segments that have sequence or position based meaning. We are seeking to have this out-dated method of data interpretation to be relaxed. The HL7 data types have provided a more robust method for several versions now for precisely distinguishing among iterations of fields associated with the XCN, XPN, XAD, and XTN data types. Similarly, a mechanism exists to distinguish between the first and second triplets of the CWE and CNE data type. Recognizing that sequence or position based meaning is not reliable, the US Healthcare Information technology Standards Panel (HITSP) requires that the “type” and “authority” components of these data types be present when multiple iterations occur.

This is a joint proposal from Quest Diagnostics and Kaiser Permanente seeking that language be inserted in the affected yields stating: As of v2.7 in the US Realm, when multiple iterations of this field are present, the “type” code is required. No assumptions can be made based on sequence or position.

Proposed Solution

Part A: XCN and XPN fields.

The HL7 standard provides for identifying the name type and identifier type of a person. There is no longer a need for meaning based on iteration or sequence. In particular the US realm is requiring the use of the Name Type Code and the Identifier Type code in fields associated with the XCN or XPN data types. The exception is where the field is an echo back and the information was not originally provided.

Insert statement in the relevant fields as follows:

As of v2.7, in the US Realm, when multiple names are transmitted the Name Type Code and Identifier Code are required. If multiple identifiers are transmitted, the Assigning Authority is required. No assumptions can be safely made based on position or sequence.


This applies to the following fields:

PID-5

PV1-7

PV1-8

PV1-9

PV1-17

NK1-2

NK1-30


Part B: XAD fields.

In the US realm, for fields associated with the XAD data type, Address Type is required but may be empty. Given the current values in table 0190, no realistic assumption can be made as to what might be construed as the primary address. There is no value “primary address.”

Insert statement in the relevant XAD fields as follows:

As of v2.7, in the US Realm, when multiple addresses are transmitted, the Address Type Code is required. No assumptions can be safely made based on position or sequence.

This applies to the following fields:

PID-11

NK1-4

NK1-32

Part C: XTN fields.

Finally, although not addressed by HITSP, for fields associated with the XTN data type, when multiple communication numbers or information is transmitted, best practice should be to populate the XTN-2 Telecommunication Use Code and XTN-3 Telecommunication Equipment Type. Given the current values in tables 0201 and 0202, no realistic assumption can be made as to what might be construed as the primary number. If only 1 number is sent, it is highly likely that the information recipient has no idea regarding the nature of the number.

Insert statement in the relevant XTN fields as follows:

As of v2.7, in the US Realm, when multiple telecommunication data are transmitted, the XTN-2 Telecommunication Use Code and XTN-3 Telecommunication Equipment Type should be populated. No assumptions can be safely made based on position or sequence.


This applies to the following fields:

PID-13

NK1-5

NK1-31

Change Name of PID-13 from Phone Number – Home to Telecommunication Information.

Retain PID-14 for Backwards Compatibility only.

Change Name of NK1-5 from Phone Number –to Telecommunication Information.

Retain NK1-6 for Backwards Compatibility only.

Change Name of NK1-31 from Contact Person’s Telephone Number – to Telecommunication Information.


Part D: CWE and CNE fields.

In the US Realm components 3 and 6 are required for fields associated with the CWE data type when CWE.1 or CWE.4 is populated. The same principle would apply to CNE.

Insert statement in the relevant CWE and CNE fields as follows:

As of v2.7, in the US Realm, requires that components 3 and 6 be populated when CWE.1 or CWE.4 is populated. No assumptions can be safely made based on position.

This applies to many fields, but we are most interested in the following:

PID-8

PID-22

Version 3 Implications

TBD