HL7 CX Extended Composite ID with Check Digit
HL7 datatype components CX components from HL7 v2.5.1 Hide components
These are the generated components for the version selected at the top of the page. The article stays practical, and this panel follows the chosen HL7 version.
Components
| Pos | Component | Name | Type | Table | Description |
|---|---|---|---|---|---|
| 1 | CX.1 | ID Number | ST | ID Number; Type ST. | |
| 2 | CX.2 | Check Digit | ST | Check Digit; Type ST. | |
| 3 | CX.3 | Check Digit Scheme | ID | 0061 | Check Digit Scheme; Type ID; HL7 table 0061. |
| 4 | CX.4 | Assigning Authority | HD | 0363 | Assigning Authority; Type HD; HL7 table 0363. |
| 5 | CX.5 | Identifier Type Code | ID | 0203 | Identifier Type Code; Type ID; HL7 table 0203. |
| 6 | CX.6 | Assigning Facility | HD | Assigning Facility; Type HD. | |
| 7 | CX.7 | Effective Date | DT | Effective Date; Type DT. | |
| 8 | CX.8 | Expiration Date | DT | Expiration Date; Type DT. | |
| 9 | CX.9 | Assigning Jurisdiction | CWE | Assigning Jurisdiction; Type CWE. | |
| 10 | CX.10 | Assigning Agency or Department | CWE | Assigning Agency or Department; Type CWE. |
CX is the datatype you use when an identifier needs to explain itself. The value might be a medical record number, national health identifier, visit number, account number, insurance member number, newborn link, or some other ID that only makes sense when you know who assigned it and what kind of identifier it is.
You see CX all over patient administration and identity workflows: PID-3 Patient Identifier List, PID-18 Patient Account Number, PID-21 Mother's Identifier, PV1-19 Visit Number, merge segments such as MRG, insurance fields, guarantor fields, and plenty of local profile-specific identifiers.
The common mistake is sending only 123456 and calling the job done. Inside one small system that might be enough. Across an enterprise, a registry, a billing feed, or a health information exchange, it is a support ticket waiting to hatch. CX exists because an ID number without authority and type is only half an identifier.
This example carries two patient identifiers. The first is a local medical record number from CITYHOSP. The second is a national identifier from a nationally assigned namespace. The value, assigning authority, and identifier type work together. Take any one of those away and the receiver has to guess.
CX-1: ID Number
This is the actual identifier value. It may be an MRN, MPI ID, visit number, account number, policy number, or national identifier, depending on the field and the implementation guide. It is the most visible component, but it is not the whole story.
Do not assume CX-1 is globally unique. The same value can exist in two facilities, two source systems, two historical numbering schemes, or two countries. In a patient identifier list, the safest habit is to pair CX-1 with CX-4 Assigning Authority and CX-5 Identifier Type Code. If the source has only the number, document that limitation clearly.
CX-2 and CX-3: Check Digit Details
CX-2 carries a check digit and CX-3 says which check digit scheme was used. In a lot of modern interfaces these components are empty, especially when identifiers are alphanumeric or when the receiver validates the identifier some other way. That is normal.
Do not calculate a check digit just because the datatype has a place for one. A check digit is meaningful only when the identifier system already uses that scheme and both sides agree on it. If a local MRN includes a self-checking digit, send the one that belongs to the identifier. If it does not, leave CX-2 and CX-3 empty.
CX-4 and CX-6: Assigning Authority and Assigning Facility
CX-4 is the assigning authority, and this is usually the most important component after the ID number itself. It uses the HD datatype, so it can carry a local namespace, a universal ID such as an OID, and the universal ID type. In a field like PID-3, this is what turns 123456 into "123456 as assigned by CITYHOSP".
CX-6 is the assigning facility. It is also an HD value, but it is not the same thing as the assigning authority. Think of CX-4 as the namespace owner and CX-6 as the facility context for where the identifier was assigned or first used. In small feeds those may be the same or CX-6 may be empty. In enterprise feeds, confusing them can create duplicate patients, broken visit matching, and very long reconciliation calls.
This is also where transformation discipline matters. In Integration Soup or any other engine, build the authority deliberately from the source system, facility, and profile rules. A general helper such as Default() can be handy for optional source text, but it should not be used to quietly replace a missing assigning authority with a plausible-looking value. If the authority is required for matching and it is missing, route or flag the problem.
CX-5: Identifier Type Code
CX-5 tells the receiver what sort of identifier is in CX-1. Common values include medical record number, account number, visit number, national identifier, social security number, employee number, and many local/profile-specific choices. HL7 table 0203 is the usual reference point, but local implementation guides often constrain the allowed values.
This component is not decoration. The same assigning authority can issue more than one kind of identifier, and a patient can carry several identifiers in one repeating field. 123456^^^CITYHOSP^MR and 123456^^^CITYHOSP^VN should not be treated as the same thing just because the number matches.
CX-7 and CX-8: Effective and Expiration Dates
CX-7 and CX-8 say when the identifier became valid and when it stopped being valid. These are not heavily populated in everyday ADT feeds, but they matter in identity management, eligibility, insurance, temporary identifiers, staff identifiers, and long-lived registry feeds.
The trap is using dates without agreeing what they mean. An effective date might be the date the identifier was issued, the date the source system learned it, or the date the receiver should start using it. If your matching or deactivation logic depends on these dates, write that meaning into the interface spec.
CX-9 and CX-10: Assigning Jurisdiction and Agency
CX-9 carries the assigning jurisdiction, and CX-10 carries the assigning agency or department. Both use CWE, which lets the value be coded when a profile needs structured detail. These components are usually empty in simple local feeds, but they become useful when identifiers come from government agencies, state registries, licensing boards, public health programs, or other authorities where "who assigned it" needs more than a namespace string.
If your national identifier, insurance identifier, or registry identifier has an issuing jurisdiction, use the code system your implementation guide expects. Do not stuff a display-only phrase into the assigning authority and hope downstream reporting can infer the agency later.
Where CX Shows Up Most
PID-3 is the big one. It repeats because patients usually have more than one identifier: local MRN, enterprise ID, national ID, temporary emergency ID, historical merged ID, and sometimes payer or registry identifiers. Put each identifier in its own repeat and let CX-4 and CX-5 explain it.
Visit and account workflows use CX in places like PV1-19 Visit Number and PID-18 Patient Account Number. Do not blur those with the patient identifier. A patient can have many visits and many accounts. Billing, orders, results, bed management, and document systems all care about the difference.
Merge and change workflows depend on CX being precise. When an MRG segment says which old identifier is being replaced or merged, a naked ID is dangerous. The old and new identifiers need their authorities and types, otherwise the receiver cannot be certain which record is being changed.
Practical Implementation Advice
When you design a CX mapping, decide the identifier policy before you write the transform. Which identifier is primary? Which identifiers repeat? Which assigning authority names are local strings, and which should be represented as OIDs or other universal IDs in HD? Which identifier type codes does the receiver actually understand?
For patient identity, prefer one good repeat over three half-populated repeats. 123456^^^CITYHOSP&1.2.3.4.5&ISO^MR is far more useful than 123456. If you cannot supply an assigning authority, be honest in the interface agreement and avoid pretending the identifier is safer than it is.
HL7 Soup Web is useful for this kind of review because it splits repeating fields and components, shows where the cursor is in the raw message, and turns table-backed values such as identifier type into readable descriptions. That makes it easier to spot a bare PID-3 value before it gets copied into another system.
Official Description and References
The HL7 v2+ logical model describes CX as the extended composite ID with check digit and says it is used for specifying an identifier with associated administrative detail. It also notes that check digit and check digit scheme are null when the ID is alphanumeric. The HL7 v2.5.1 component panel in this guide lists the ten CX components available for the default reference version.
For formal reference, compare the generated component panel above with the HL7 v2+ CX logical model and HL7 terminology table 0203 for identifier type codes.
Related Datatypes and Segments
For nearby datatype work, look at HD for assigning authorities, EI for entity identifiers, CWE for jurisdiction and agency coding, and XPN for person names. For common segment uses, start with PID-3, PID-18, PID-21, PV1-19, MRG, and insurance segments such as IN1.