HL7 CTD Contact Data
HL7 field reference CTD fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
| Field | Name | Required | Repeatable | Type | Table |
|---|---|---|---|---|---|
| CTD.1 | Contact Role | Yes | Yes | CE | 0131 |
| CTD.2 | Contact Name | No | Yes | XPN | |
| CTD.3 | Contact Address | No | Yes | XAD | |
| CTD.4 | Contact Location | No | No | PL | |
| CTD.5 | Contact Communication Information | No | Yes | XTN | |
| CTD.6 | Preferred Method of Contact | No | No | CE | 0185 |
| CTD.7 | Contact Identifiers | No | Yes | PLN |
CTD carries structured contact details for a person or organization associated with an order, referral, provider, location, or service.
The standard describes CTD this way: The CTD segment may identify any contact personnel associated with a patient referral message and its related transactions. The CTD segment will be paired with a PRD segment. The PRD segment contains data specifically focused on provider information in a referral. While it is important in an inter-enterprise transaction to transmit specific information regarding the providers involved (referring and referred-to), it may also be important to identify the contact personnel associated with the given provider. For example, a provider receiving a referral may need to know the office manager or the billing person at the institution of the provider who sent the referral. This segment allows for multiple contact personnel to be associated with a single provider.
Consent and contact segments sit close to real-world accountability. They describe who may be contacted, who consented, what was agreed, when it applies, and which limits matter.
Do not use these fields as a vague note pad. If the receiving workflow relies on consent state, contact role, or contact method, the coded values and dates need to be explicit.
The v2.5.1 structures show CTD in OMG_O19 - OMG - General clinical order, OMI_O23 - OMI - Imaging order, OML_O21 - OML - Laboratory order, and ORF_R04 - ORF - Response to query; transmission of requested observation, and 16 other message structures. That tells you where it can appear, but the implementation guide still decides which optional fields are meaningful.
For practical interface work, read the generated field panel for datatype, required, repeatable, and table details, then use the notes below to decide what the field should mean in the receiving workflow.
CTD-1 identifies a person, provider, staff member, or contact involved in this consent or contact record. Use the structured name or provider datatype instead of flattening everything into display text.
When more than one person is sent, repeats should carry role or identifier context so the receiver can tell who did what.
CTD-2 identifies a person, provider, staff member, or contact involved in this consent or contact record. Use the structured name or provider datatype instead of flattening everything into display text.
When more than one person is sent, repeats should carry role or identifier context so the receiver can tell who did what.
CTD-3 carries contact details. Use the datatype components for use code, equipment type, address type, country, and other qualifiers rather than squeezing everything into one formatted string.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
CTD-4 identifies a person, provider, staff member, or contact involved in this consent or contact record. Use the structured name or provider datatype instead of flattening everything into display text.
CTD-5 identifies a person, provider, staff member, or contact involved in this consent or contact record. Use the structured name or provider datatype instead of flattening everything into display text.
When more than one person is sent, repeats should carry role or identifier context so the receiver can tell who did what.
CTD-6 qualifies the consent or contact record rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
Use the agreed value set, starting from HL7 table 0185. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
CTD-7 identifies the Contact Identifiers for this consent or contact record. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
If there are several identifiers, use repetitions deliberately and make each repeat self-explanatory rather than relying on position alone.