Template  CX - Extended composite ID with check digit

The check digit in this data type is not an add-on produced by the message processor. It is the check digit that is part of the identifying number used in the sending application. If the sending application does not include a self-generated check digit in the identifying number, this component should be valued null.

Contains the code identifying the check digit scheme employed.

Refer to HL7 Table 0061 - Check digit scheme for valid values.

The algorithm for calculating a Mod10 check digit is as follows:

Assume you have an identifier - 12345. Take the odd digit positions, counting from the right, i.e., 531, multiply this number by 2 to get 1062. Take the even digit positions, starting from the right (i.e., 42), prepend these to the 1062 to get 421062. Add all of these six digits together to get 15. Subtract this number from the next highest multiple of 10, i.e., 20 - 15 to get 5. The Mod10 check digit is 5. The Mod10 check digit for 401 is 0; for 9999, it’s 4; for 99999999, it’s 8.

The algorithm for calculating a Mod11 check digit is as follows:

Terms

Calculation

Example:

If the number is 1234567, then the mod 11 check digit = 4

The calculations are:

M = (7*2)+(6*3)+(5*4)+(4*5)+(3*6)+(2*7)+(1*2)
= 14 + 18 + 20 + 20 + 18 + 14 + 2
= 106
c1 = 106 mod 11
= 7
c = (11-c1) mod 10
= 4 mod 10
= 4

Other variants of these check digit algorithms exist and may be used by local bilateral site agreement.

Note: The check digit and code identifying check digit scheme are null if ID is alphanumeric.

The assigning authority is a unique name of the system (or organization or agency or department) that creates the data. . Refer to User-defined Table 0363 – Assigning authority for suggested values.

The reader is referred to the CX.9 and the CX.10 if there is a need to transmit values with semantic meaning for an assigning jurisdiction or assigning department or agency in addition to, or instead of, an assigning authority. However, all 3 components may be valued. If, in so doing, it is discovered that the values in CX.9 and/or CX.10 conflict with CX.4, the user would look to the Message Profile or other implementation agreement for a statement as to which takes precedence.

Note: When the HD data type is used in a given segment as a component of a field of another data type, User-defined Table 0300 - Namespace ID (referenced by the first sub-component of the HD component) may be re-defined (given a different user-defined table number and name) by the technical committee responsible for that segment.

By site agreement, implementers may continue to use User-defined Table 0300 – Namespace ID for the first sub-component.

The place or location identifier where the identifier was first assigned to the patient. This component is not an inherent part of the identifier but rather part of the history of the identifier: as part of this data type, its existence is a convenience for certain intercommunicating systems.

Note: When the HD data type is used in a given segment as a component of a field of another data type, User-defined Table 0300 - Namespace ID (referenced by the first sub-component of the HD component), may be re-defined (given a different user-defined table number and name) by the technical committee responsible for that segment.

The geo-political body that assigned the identifier in component 1.

• Refer to HL7 Table 0399 Country Code in section 2.15.9.17 for valid values if the administrative unit under whose jurisdiction the identifier was issued is a country.
• Refer to User-Defined Table 0347 State/Province for suggested values if the administrative unit under whose jurisdiction the identifier was issued is a state or province. This table is country specific. In the US postal codes may be used.
• Refer to User-defined Table –0289 County/Parish for suggested values if the administrative unit under whose jurisdiction the identifier was issued is a county or parish.

The reader is referred to the CX.4, if there is a need to transmit this information as an OID

The agency or department that assigned the identifier in component 1.

Refer to User-defined Table –0530 Organizations, Agency, Department for suggested values if the administrative unit under whose jurisdiction the identifier was issued is an organization, agency or department. This is populated with site-specific assigning authorities. It also should contain national or international codes when CX-5 Identifier Type may be assigned by more than one authority within a governmental or organizational unit. For example, a federal government may have 2 departments that assign a military identifier, its Veterans Affairs department and its department of defense. It is not recommended to include values for entities such as Social Security Administration (SSA), Immigration and Naturalization Service (INS), Center for Medicare and Medicaid Services (CMS) because they are included in the identifier type table. In these cases the name of the country plus the identifier type yields the correct interpretation of the identifier in component one. Likewise, entries like department of motor vehicles (DMV) and licensing boards are not recommended for inclusion because the combination of state and identifier type yields the correct interpretation of the identifier in component one. This approach is not to be confused with the detailed information provided in the chapter 15 segments that have provision for specifying the precise granting body and issuing body information needed in personnel management messages.

Example 1: <Identifier> plus <Visa> yields a unique identifier.

Example 2: <Identifier> plus <state> plus <DLN> yields a unique driver’s license number.

Example 3: <Identifier> plus <country> plus <INS> yields a unique immigration number.

The reader is referred to the CX.4, if there is a need to transmit this information as an OID.