The CTD (Contact Data) segment carries information about the people and organizations associated with a referral and the role each one plays. It travels alongside the provider data described by the PRD segment and adds the addressing, telephony, and role detail that lets the receiving system reach the right person about the patient.
CTD answers the practical question of "who do I contact, and how" for a referral. A single referral can include several CTD segments because each contact may play a different role, and each CTD instance can itself carry repeating names, addresses, and communication numbers.
Purpose
The CTD segment describes a contact related to a referral: their role, name, address, location, communication numbers, preferred contact method, and identifiers. It supplements the provider information in PRD so that the referred-to organization or clinician can be reached without ambiguity.
CTD is used when a referral needs to name a specific person to call, fax, or write to, distinct from the provider whose credentials and specialties are described in PRD.
Used in
CTD (Contact Data) follows PRD in REF (patient referral) messages. See REF referral messages.
- REF^I12 and other REF events use a repeating provider group in which PRD is followed by one or more CTD segments.
- Each CTD names one contact for the provider or organization just described by the preceding PRD.
Field-by-field reference
Source: HAPI HL7v2 v2.5.1 javadocs (CTD.html). Length is shown as —; Required and Table # come from the HL7 v2.5.1 standard where well-established.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| CTD-1 | Contact Role | ce | — | R | Y | HL70131 | Role this contact plays in the referral |
| CTD-2 | Contact Name | xpn | — | O | Y | — | Name of the contact person |
| CTD-3 | Contact Address | xad | — | O | Y | — | Mailing or physical address of contact |
| CTD-4 | Contact Location | pl | — | O | — | — | Point of care or location of contact |
| CTD-5 | Contact Communication Information | xtn | — | O | Y | — | Phone, fax, email and other numbers |
| CTD-6 | Preferred Method of Contact | ce | — | O | — | HL70185 | Preferred way to reach this contact |
| CTD-7 | Contact Identifiers | pln | — | O | Y | — | Practitioner license or other identifiers |
Most-used fields
- CTD-1 Contact Role: the only required field, and the one that gives every other field meaning. It says whether the contact is the referring person, an emergency contact, a guarantor, or another role.
- CTD-2 Contact Name: the human-readable name used when staff need to phone or write to the contact.
- CTD-5 Contact Communication Information: the repeating telephony field that holds phone, fax, and email values, normalized so each entry carries its own use code.
- CTD-3 Contact Address: the postal address, frequently populated for organizational contacts that receive mailed correspondence.
- CTD-6 Preferred Method of Contact: a small but useful hint that tells the receiver whether to call, fax, or email first.
Version differences (2.3 to 2.8.2)
- 2.3: CTD appears within the referral chapter with its core role, name, address, and communication fields established.
- 2.3.1 to 2.4: Field set remains stable; data type definitions for XPN, XAD, and XTN are extended with additional components that CTD inherits.
- 2.5 and 2.5.1: CTD carries the seven fields documented here, with CTD-7 Contact Identifiers typed as PLN.
- 2.6 to 2.8.2: The segment is largely unchanged in shape; later versions refine the underlying complex data types (for example richer XTN components) rather than adding new CTD fields.
Always validate field cardinality against the specific version negotiated with your trading partner, because component-level differences in XPN, XAD, and XTN can affect parsing even when the segment layout is identical.
Common mistakes
- Omitting CTD-1 Contact Role: it is required, and leaving it blank makes the rest of the segment ambiguous to the receiver.
- Treating CTD-2 as a single name when it repeats: collapsing multiple names into one field loses alternate or legal-name detail.
- Stuffing phone, fax, and email into one CTD-5 repetition instead of separate repetitions each with its own use code.
- Confusing CTD with PRD: PRD describes the provider's credentials and specialties, while CTD describes how to reach a specific contact.
- Placing CTD before PRD: CTD must follow the PRD it qualifies within the referral group.
Examples
Minimal CTD with only the required role and a name:
CTD|RP^Referring Provider^HL70131|Reyes^Mara^L
Fully populated CTD:
CTD|RP^Referring Provider^HL70131|Reyes^Mara^L^^Dr^MD|400 Cedar St^Suite 12^Lakeside^OR^97001^USA|^^^Lakeside Family Clinic|^WPN^PH^^1^503^5550148~^NET^Internet^mreyes@example-clinic.test|PH^Phone^HL70185|9988776655^^^OR
Annotated breakdown:
CTD-1 RP^Referring Provider^HL70131 Contact role = referring provider
CTD-2 Reyes^Mara^L^^Dr^MD Contact name with prefix and degree
CTD-3 400 Cedar St^Suite 12^... Contact mailing address
CTD-4 ^^^Lakeside Family Clinic Contact location / point of care
CTD-5 ^WPN^PH^...~^NET^Internet^... Work phone, then email (two repetitions)
CTD-6 PH^Phone^HL70185 Preferred method of contact = phone
CTD-7 9988776655^^^OR Contact identifier (license number)
In-context excerpt within a REF^I12 referral (CTD follows PRD):
MSH|^~&|REFSYS|CLINIC_A|EHR|HOSP_B|20260610113000||REF^I12^REF_I12|MSG00041|P|2.5.1
PRD|RP^Referring Provider^HL70131|Reyes^Mara^L^^Dr^MD|400 Cedar St^Suite 12^Lakeside^OR^97001|||9988776655^^^OR
CTD|RP^Referring Provider^HL70131|Reyes^Mara^L|400 Cedar St^Suite 12^Lakeside^OR^97001^USA||^WPN^PH^^1^503^5550148|PH^Phone^HL70185
A second in-context excerpt showing two contacts for one referral group:
PRD|RT^Referred To Provider^HL70131|Okafor^Daniel^J^^Dr^MD|18 Harbor Rd^^Lakeside^OR^97001
CTD|RT^Referred To Provider^HL70131|Okafor^Daniel^J|18 Harbor Rd^^Lakeside^OR^97001^USA||^WPN^PH^^1^503^5550199|PH^Phone^HL70185
CTD|EP^Emergency Contact^HL70131|Okafor^Lena|18 Harbor Rd^^Lakeside^OR^97001^USA||^NET^Internet^lokafor@example-clinic.test|NET^Internet^HL70185
FHIR mapping
- Source: CTD
- Target: Not mapped at the segment level.
- Notes: No segment-level ConceptMap is published in the v2-to-FHIR IG for CTD. Conceptually CTD describes a contact and maps toward a Practitioner or Organization.contact role, or a RelatedPerson, rather than to a standalone resource.
When integrating to FHIR, treat each CTD as a contact participant: CTD-1 informs the contact role, CTD-2 the name, CTD-3 the address, and CTD-5 the telecom entries, distributed onto whichever resource (Practitioner, Organization.contact, or RelatedPerson) best fits the role.
Engine considerations
- Expect CTD to repeat within a referral group; iterate the PRD/CTD group rather than reading a single instance.
- Preserve CTD-5 repetitions individually so phone, fax, and email use codes survive the transform.
- Keep the CTD-1 coding system component intact; downstream role mapping depends on it.
- Validate that CTD-1 is present before accepting the segment, since it is required.
- Watch for partner-specific component differences in XPN and XTN across versions.
How Vorro parses and produces CTD
- On inbound messages, Vorro reads each CTD in document order within its PRD group and exposes the fields as structured contact records keyed by CTD-1 role.
- Repeating fields (CTD-2, CTD-3, CTD-5, CTD-7) are normalized into lists so no repetition is silently dropped.
- On outbound messages, Vorro emits CTD-1 first and only writes optional fields that have values, keeping segments compact.
- Telecom values are written as separate CTD-5 repetitions, each with an explicit use and equipment type, to match receiver expectations.
- Role and preferred-method codes are validated against the configured tables before the segment is produced.
