HL7 CON Consent Segment
HL7 field reference CON 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 |
|---|---|---|---|---|---|
| CON.1 | Set ID - CON | Yes | No | SI | |
| CON.2 | Consent Type | No | No | CWE | 0496 |
| CON.3 | Consent Form ID | No | No | ST | |
| CON.4 | Consent Form Number | No | No | EI | |
| CON.5 | Consent Text | No | Yes | FT | |
| CON.6 | Subject-specific Consent Text | No | Yes | FT | |
| CON.7 | Consent Background | No | Yes | FT | |
| CON.8 | Subject-specific Consent Background | No | Yes | FT | |
| CON.9 | Consenter-imposed limitations | No | Yes | FT | |
| CON.10 | Consent Mode | No | No | CNE | 0497 |
| CON.11 | Consent Status | Yes | No | CNE | 0498 |
| CON.12 | Consent Discussion Date/Time | No | No | TS | |
| CON.13 | Consent Decision Date/Time | No | No | TS | |
| CON.14 | Consent Effective Date/Time | No | No | TS | |
| CON.15 | Consent End Date/Time | No | No | TS | |
| CON.16 | Subject Competence Indicator | No | No | ID | 0136 |
| CON.17 | Translator Assistance Indicator | No | No | ID | 0136 |
| CON.18 | Language Translated To | No | No | ID | 0296 |
| CON.19 | Informational Material Supplied Indicator | No | No | ID | 0136 |
| CON.20 | Consent Bypass Reason | No | No | CWE | 0499 |
| CON.21 | Consent Disclosure Level | No | No | ID | 0500 |
| CON.22 | Consent Non-disclosure Reason | No | No | CWE | 0501 |
| CON.23 | Non-subject Consenter Reason | No | No | CWE | 0502 |
| CON.24 | Consenter ID | Yes | Yes | XPN | |
| CON.25 | Relationship to Subject Table | Yes | Yes | IS | 0548 |
CON carries consent information for a procedure, admission, information release, employee/service-provider consent, or another consent-sensitive event in the message.
The standard describes CON this way: This segment identifies patient consent information relating to a particular message. It can be used as part of existing messages to convey information about patient consent to procedures, admissions, information release/exchange or other events discussed by the message. It may also be used in messages focusing on recording or requesting consent and for consents related to employees or service providers. The segment will be used in conjunction with various other segments to identify the practitioner (PRA/STF) or patient (PID) the consent is for, the various individuals involved in the consent (ROL) as witnesses, consenting person (not always the patient), translators, consulting providers, etc., and the specific procedures being proposed (PR1).
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 imported v2.5.1 message-structure catalog does not list a common message structure for CON here, so I would treat it as profile-driven. Use it when your sending and receiving systems have explicitly agreed how the segment is carried.
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.
CON-1 is the sequence number for this CON segment within its repeating group. It keeps multiple CON lines in order; it is not the business identifier for the consent or contact record.
CON-2 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 0496. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
CON-3 identifies the Consent Form ID 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.
CON-4 identifies the Consent Form Number 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.
CON-5 is human-readable context. Keep it useful for display and troubleshooting, but do not hide required workflow logic here unless the implementation guide explicitly says the receiver parses it.
Because the field can repeat, separate distinct statements into separate repetitions instead of creating one long hard-to-parse block.
CON-6 is human-readable context. Keep it useful for display and troubleshooting, but do not hide required workflow logic here unless the implementation guide explicitly says the receiver parses it.
Because the field can repeat, separate distinct statements into separate repetitions instead of creating one long hard-to-parse block.
CON-7 carries Consent Background for this consent or contact record. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
CON-8 carries Subject-specific Consent Background for this consent or contact record. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
CON-9 narrows what is allowed for this consent or contact record. These values are policy-sensitive, so keep the text or code close to the consent, privacy, or profile rule that created it.
Use separate repetitions for separate limits so a receiver can display or enforce them without parsing a paragraph.
CON-10 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 0497. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
CON-11 tells the receiver the state of this consent or contact record. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0498 or the narrower table in the local profile.
CON-12 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
CON-13 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
CON-14 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
For effective and end dates, make the boundary rule explicit. Receivers need to know whether the value is inclusive, exclusive, planned, actual, or merely informational.
CON-15 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
For effective and end dates, make the boundary rule explicit. Receivers need to know whether the value is inclusive, exclusive, planned, actual, or merely informational.
CON-16 tells the receiver the state of this consent or contact record. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0136 or the narrower table in the local profile.
CON-17 tells the receiver the state of this consent or contact record. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0136 or the narrower table in the local profile.
CON-18 carries Language Translated To for this consent or contact record. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0296; many real interfaces narrow that list further, so follow the receiver's implementation guide.
CON-19 tells the receiver the state of this consent or contact record. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0136 or the narrower table in the local profile.
CON-20 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 0499. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
CON-21 narrows what is allowed for this consent or contact record. These values are policy-sensitive, so keep the text or code close to the consent, privacy, or profile rule that created it.
The generated panel links this to HL7 table 0500; many real interfaces narrow that list further, so follow the receiver's implementation guide.
CON-22 narrows what is allowed for this consent or contact record. These values are policy-sensitive, so keep the text or code close to the consent, privacy, or profile rule that created it.
The generated panel links this to HL7 table 0501; many real interfaces narrow that list further, so follow the receiver's implementation guide.
CON-23 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 0502. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
CON-24 identifies the Consenter ID 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.
CON-25 carries Relationship to Subject Table for this consent or contact record. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0548; many real interfaces narrow that list further, so follow the receiver's implementation guide.