HL7 DB1 Segment: Disability

The DB1 (Disability) segment carries information about a patient's disability status as part of a registration or admission message. It records whether a person is considered disabled, which party the disability applies to, the identifiers tied to that disabled person, and the relevant dates: when the disability started and ended, when the patient became unable to work, and when they are expected to return to work.

DB1 is a repeating segment — a single message can carry several DB1 instances when multiple disabilities or multiple disabled parties (patient, guarantor, insured) are relevant. It is positioned after the demographic context so that the disability data attaches cleanly to the person already identified by PID.

Purpose

The DB1 segment exists to convey disability status and its associated dates within patient-administration workflows. Its responsibilities are:

Indicate whether the relevant person is disabled (DB1-4 Disabled Indicator).
Identify which party the disability applies to via DB1-2 Disabled Person Code.
Carry one or more identifiers for the disabled person (DB1-3, repeating).
Record the disability timeline: start, end, unable-to-work, and return-to-work dates.

This lets registration, eligibility, and billing systems determine disability-related benefits and reporting obligations without parsing free text.

Used in

DB1 carries patient disability data in ADT registration and admit messages. It is commonly seen after PID in an ADT admit (A01) or registration flow, where disability status influences eligibility, coverage, and downstream reporting. Because the segment repeats, a single admit message can describe disability for the patient and for other associated parties when applicable. The visit context in PV1 accompanies the disability data in these messages.

Field-by-field reference

Source: HAPI HL7v2 v2.5.1 javadocs (DB1.html). Lengths are shown as —; Required and Table # values are taken from the HL7 v2.5.1 standard where well-established.

Seq	Name	Data Type	Length	Req	Repeat	Table #	Description
DB1-1	Set ID - DB1	si	—	R	—	—	Sequence number for this DB1 repetition
DB1-2	Disabled Person Code	is	—	O	—	HL70334	Identifies which party the disability applies to
DB1-3	Disabled Person Identifier	cx	—	O	Y	—	One or more identifiers for the disabled person
DB1-4	Disabled Indicator	id	—	O	—	HL70136	Indicates whether the person is disabled
DB1-5	Disability Start Date	dt	—	O	—	—	Date the disability began
DB1-6	Disability End Date	dt	—	O	—	—	Date the disability ended
DB1-7	Disability Return to Work Date	dt	—	O	—	—	Expected or actual return-to-work date
DB1-8	Disability Unable to Work Date	dt	—	O	—	—	Date the person became unable to work

Most-used fields

DB1-1 Set ID - DB1 — required ordinal that distinguishes repeated DB1 segments in a message.
DB1-2 Disabled Person Code — tells the receiver which party (patient, guarantor, insured) is disabled.
DB1-4 Disabled Indicator — the core yes/no flag many downstream systems key on.
DB1-5 Disability Start Date — anchors benefit and coverage windows.
DB1-7 Disability Return to Work Date — drives return-to-work and short-term-disability tracking.

DB1-3 Disabled Person Identifier is used when a system needs to tie the disability to a specific external identifier; it repeats to allow more than one identifier.

Version differences (2.3 to 2.8.2)

2.3: The DB1 segment was introduced to carry disability data in patient-administration messages, establishing the Set ID, disabled-person code, indicator, and date fields.
2.4: Field semantics and ordering remained stable; the segment continued to be used in ADT registration/admit flows.
2.5 / 2.5.1: The eight-field structure shown here is in effect, with DB1-3 modeled as a repeating CX identifier. This matches the HAPI v2.5.1 model.
2.6 through 2.8.2: The segment definition stays essentially unchanged. Underlying types (for example CX) gain refinements, but DB1 field count, ordering, and meaning are preserved. Confirm exact lengths and table bindings against the target system's conformance profile.

Common mistakes

Omitting DB1-1 Set ID. It is required and must increment across repeated DB1 segments; receivers may reject the message otherwise.
Confusing DB1-7 Return to Work Date with DB1-8 Unable to Work Date. Unable-to-work is when work stopped; return-to-work is when it resumes.
Treating DB1-3 as single-valued. It is a repeating CX field and may carry multiple identifiers.
Assuming DB1 always refers to the patient. DB1-2 Disabled Person Code can designate a different party, so do not hard-code the subject.
Sending disability dates in timestamp format. DB1-5 through DB1-8 are DT (date only), not TS.

Examples

Minimal DB1 — set ID, disabled indicator, and a start date:

DB1|1||| Y|20260101

A cleaner minimal form without the stray space:

DB1|1|||Y|20260101

Fully populated DB1 — disabled person code, repeating identifier, indicator, and full date set:

DB1|1|PT^Patient^HL70334|DPID778899^^^SSA^SS~MRN556677^^^MERCY^MR|Y|20251015|20260401|20260415|20251010

Annotated breakdown of the fully populated example:

DB1                                 Segment ID (Disability)
1                                   DB1-1 Set ID - DB1 (SI)
PT^Patient^HL70334                  DB1-2 Disabled Person Code (IS)
DPID778899^^^SSA^SS~MRN556677^...   DB1-3 Disabled Person Identifier (CX, repeating)
Y                                   DB1-4 Disabled Indicator (ID)
20251015                            DB1-5 Disability Start Date (DT)
20260401                            DB1-6 Disability End Date (DT)
20260415                            DB1-7 Disability Return to Work Date (DT)
20251010                            DB1-8 Disability Unable to Work Date (DT)

In-context excerpt — DB1 following PID in an ADT^A01 admit message:

MSH|^~&|REG|MERCY|ADT|REGIONAL|20260101080000||ADT^A01^ADT_A01|MSG00451|P|2.5.1
EVN|A01|20260101080000
PID|1||MRN556677^^^MERCY^MR||Alvarez^Renata^J||19840312|F
PV1|1|I|3W^312^A^MERCY||||1004^Nguyen^Carla^^^^MD|||MED
DB1|1|PT^Patient^HL70334|DPID778899^^^SSA^SS|Y|20251015|||20251010

In-context excerpt — multiple repeating DB1 segments in an ADT^A01 for patient and guarantor:

MSH|^~&|REG|MERCY|ADT|REGIONAL|20260101080000||ADT^A01^ADT_A01|MSG00452|P|2.5.1
EVN|A01|20260101080000
PID|1||MRN556677^^^MERCY^MR||Alvarez^Renata^J||19840312|F
DB1|1|PT^Patient^HL70334|DPID778899^^^SSA^SS|Y|20251015|||20251010
DB1|2|GT^Guarantor^HL70334|DPID991122^^^SSA^SS|Y|20240601||20260501|20240520

FHIR mapping

DB1 is not mapped at the segment level. No segment-level ConceptMap is published in the v2-to-FHIR IG for DB1.

Conceptually, DB1 aligns with Patient/Condition disability data in FHIR: the disabled indicator and person code (DB1-2, DB1-4) correspond to a disability-flag extension on Patient or to a Condition representing the disability, while the date fields (DB1-5 through DB1-8) map to Condition.onset, Condition.abatement, and related period elements. The repeating identifier (DB1-3) maps to Patient.identifier on the relevant subject. Because no normalized field-level mapping is published, treat DB1-to-FHIR translation as an integration-specific design decision and validate against the receiving FHIR profile.

Engine considerations

DB1 repeats; engines must iterate all DB1 instances and preserve DB1-1 Set ID ordering rather than collapsing to the first occurrence.
DB1-3 is itself a repeating CX field. Engines must handle the field-level repetition (the ~ separator) within each DB1 segment.
DB1-5 through DB1-8 are DT (date) fields. Do not coerce them into timestamps; preserve date-only precision.
DB1-2 and DB1-4 are table-bound. Validate against the receiver's value sets (HL70334 for the person code, HL70136 for the yes/no indicator).
Do not assume the patient is the disabled subject. Carry DB1-2 through transforms so the correct party is preserved.

How Vorro parses and produces DB1

When Vorro parses an inbound message, it reads every DB1 repetition independently, preserves each Set ID, and fully expands the repeating DB1-3 identifier list so no identifier is lost. Date fields are retained at date-only precision, and the coded fields (DB1-2, DB1-4) keep their full component structure including the coding system.

When producing DB1, Vorro emits one segment per disability subject, assigns sequential Set IDs starting at 1, and populates only the fields backed by mapped source data. Identifiers are written into DB1-3 with the correct assigning-authority and identifier-type components, and disability dates are normalized to DT format. Indicator and person-code values are drawn from the integration's configured value sets so they match the receiving system's tables. The output sits cleanly after PID in an ADT admit message.

Sources

← Back to HL7 v2 Guide