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
d
=
digit of number starting from units digit, followed by 10’s position, followed by
100’s position, etc.
w
=
weight of digit position starting with the units position, followed by 10’s position,
followed by 100’s position etc. Values for w = 2, 3, 4, 5, 6, 7, 2, 3, 4, 5, 6, 7,
etc. (repeats for each group of 6 digits)
c
=
check digit
Calculation
(Step 1) m
=
sum of (d * w) for positions 1, 2, etc. starting with units digit for d = digit value starting with units position to highest order for w = weight value from 2 to 7 for every six positions starting with units digit
(Step 2) c1
=
m mod 11
(Step 3) if c1
=
0 then reset c1 = 1
(Step 4)
=
(11 - c1) mod 10
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.
A code corresponding to the type of identifier. In some cases, this code may be used
as a qualifier to the "Assigning authority" component. Refer to HL7 Table 0203 - Identifier
type for suggested values.
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.
Template CX - Extended composite ID with check digit
Actief
Lab2Lab PID segment
The value of the identifier itself.
ype)