The SDD (Sterilization Device Data) segment was introduced in HL7 v2.7 as part of the sterilization messaging suite. It is the per-cycle counterpart to SCP: where SCP describes the device, SDD describes what that device is doing right now — which lot is loaded, what state the device is in, what the load status is, and who is operating it. SDD is the segment that turns a static sterilizer configuration into a live cycle record.
Purpose
SDD answers "what is this device doing in this cycle?" It carries the lot number, device identity, the data-state code (e.g. start of cycle, in progress, complete), the load status (e.g. loaded, empty, aborted), a numeric control code that vendors use to convey cycle outcomes, and the operator's name. SDD is the join row between the device registry (SCP) and the lot/parameter records (SLT, STZ).
Used in
SDD appears in lab automation and sterilization cycle messages:
- ESU — Equipment Status Update — most common carrier; SDD reports a state transition on a known device.
- ESR — Equipment Status Request — used in responses when a manager queries the device for its current cycle.
- Sterilization cycle messages grouping SCP, SDD, SLT, and STZ for a complete cycle record.
Field-by-field reference
Source: HAPI HL7v2 v2.8.1 javadocs (https://hapifhir.github.io/hapi-hl7v2/v281/apidocs/ca/uhn/hl7v2/model/v281/segment/SDD.html). Length —; Required and Table # from the HL7 v2 standard where well-established.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| SDD-1 | Lot Number | ei | — | R | — | — | Identifier of the sterilization lot. |
| SDD-2 | Device Number | ei | — | O | — | — | Identifier of the sterilization device. |
| SDD-3 | Device Name | st | — | O | — | — | Human-readable name of the device. |
| SDD-4 | Device Data State | cwe | — | O | — | — | Coded state of the cycle data. |
| SDD-5 | Load Status | cwe | — | O | — | — | Coded load status of the device. |
| SDD-6 | Control Code | nm | — | O | — | — | Numeric vendor cycle outcome code. |
| SDD-7 | Operator Name | st | — | O | — | — | Name of the operator running cycle. |
Most-used fields
- SDD-1 Lot Number — the primary identifier and the field receivers index on. Treated as required in practice even where the standard is permissive.
- SDD-2 Device Number — joins SDD back to the SCP that defined the device and forward to any SLT segments for the same lot.
- SDD-4 Device Data State — drives the receiver's state machine: "in progress" vs. "complete" vs. "aborted" determines whether downstream systems should treat the cycle as final.
- SDD-5 Load Status — distinguishes a loaded cycle from an empty self-test; analytics dashboards filter aggressively on this field.
- SDD-7 Operator Name — captured for traceability and is often required by hospital sterile processing audit policies even when the standard marks it optional.
Version differences (2.6 to 2.8.2)
- 2.6 — SDD did not exist; per-cycle data was carried via NTE or vendor Z-segments.
- 2.7 — SDD introduced with the seven fields shown above.
- 2.8 — No structural changes. Vocabulary on SDD-4 Device Data State and SDD-5 Load Status continued to be harmonized across vendors.
- 2.8.1 — Documented here; identical field set to 2.8 with refined CWE guidance.
- 2.8.2 — No new fields; minor clarifications around the relationship between SDD-1 Lot Number and the SLT segment.
Common mistakes
- Sending SDD without SDD-1 Lot Number — receivers cannot index the cycle and typically discard the segment.
- Using SDD-2 Device Number values that do not match any prior SCP-4 in the same message; this breaks downstream joins.
- Putting a free-text status into SDD-4 Device Data State instead of a coded CWE — analytics that bucket by state will fail.
- Treating SDD-6 Control Code as standardized; it is vendor-specific and must be interpreted with the model from SCP-6.
- Mapping SDD-7 Operator Name to a structured XCN — the standard data type is plain ST. Free text only.
- Omitting SDD entirely between SCP and SLT — without SDD there is no cycle context to attach the lot to.
Examples
Minimal SDD:
SDD|LOT-20260610-014^^STERILE-CENTRAL^EI
Fully-populated SDD:
SDD|LOT-20260610-014^^STERILE-CENTRAL^EI|STZ-AUTOCLAVE-07^^STERILE-CENTRAL^EI|Central OR Autoclave 7|IN_PROGRESS^Cycle In Progress^HL70667|LOADED^Loaded^HL70669|212|Jordan Pierce
Annotated breakdown:
SDD segment id
|LOT-20260610-014^^STERILE-CENTRAL^EI SDD-1 Lot Number (EI)
|STZ-AUTOCLAVE-07^^STERILE-CENTRAL^EI SDD-2 Device Number (EI)
|Central OR Autoclave 7 SDD-3 Device Name
|IN_PROGRESS^Cycle In Progress^HL70667 SDD-4 Device Data State
|LOADED^Loaded^HL70669 SDD-5 Load Status
|212 SDD-6 Control Code
|Jordan Pierce SDD-7 Operator Name
In-context ESU excerpt (cycle start broadcast):
MSH|^~&|STERILECTRL|CSSD|LIS|LAB|20260610090300||ESU^U01^ESU_U01|MSG00001905|P|2.8.1
EQU|STZ-AUTOCLAVE-07^^STERILE-CENTRAL^EI|20260610090300|RUNNING^Running^HL70569
SCP|1|HOURS^Hours^HL70718|YYYYMMDDHHMM^Long^HL70529|STZ-AUTOCLAVE-07^^STERILE-CENTRAL^EI|Central OR Autoclave 7|MedSteam 5000XL|STEAM^Steam Autoclave^HL70667|Y^Lot Controlled^HL70136
SDD|LOT-20260610-014^^STERILE-CENTRAL^EI|STZ-AUTOCLAVE-07^^STERILE-CENTRAL^EI|Central OR Autoclave 7|START^Cycle Started^HL70667|LOADED^Loaded^HL70669|100|Jordan Pierce
In-context ESU excerpt (cycle completion broadcast):
MSH|^~&|STERILECTRL|CSSD|LIS|LAB|20260610094500||ESU^U01^ESU_U01|MSG00001906|P|2.8.1
EQU|STZ-AUTOCLAVE-07^^STERILE-CENTRAL^EI|20260610094500|IDLE^Idle^HL70569
SCP|1|HOURS^Hours^HL70718|YYYYMMDDHHMM^Long^HL70529|STZ-AUTOCLAVE-07^^STERILE-CENTRAL^EI|Central OR Autoclave 7|MedSteam 5000XL|STEAM^Steam Autoclave^HL70667|Y^Lot Controlled^HL70136
SDD|LOT-20260610-014^^STERILE-CENTRAL^EI|STZ-AUTOCLAVE-07^^STERILE-CENTRAL^EI|Central OR Autoclave 7|COMPLETE^Cycle Complete^HL70667|UNLOADED^Unloaded^HL70669|200|Jordan Pierce
See the ESU message page for the full trigger event and segment grouping.
FHIR mapping
No segment-level ConceptMap is published in the v2-to-FHIR IG for SDD. Conceptually, SDD-1 Lot Number maps to Substance.identifier or to a sterilization-event resource extension; SDD-2/3 align with Device.identifier/Device.deviceName; SDD-4 Device Data State maps to a status code on a custom sterilization-event resource; SDD-5 Load Status, SDD-6 Control Code, and SDD-7 Operator Name typically land in Observation or Procedure components for the cycle. The broader picture: sterilization data maps to FHIR Device, DeviceMetric, and Substance resources rather than as a one-to-one segment.
Engine considerations
- Validate that SDD-1 Lot Number is present and well-formed before accepting the segment; receivers index cycles on it.
- Maintain the SCP/SDD group integrity. If your engine reorders segments for normalization, ensure each SDD remains adjacent to the SCP describing its device.
- SDD-4 Device Data State drives downstream state machines. Build a transition table and reject messages with illegal transitions (e.g. COMPLETE following ABORTED for the same lot).
- SDD-6 Control Code is numeric but vendor-specific; store the raw value plus the SCP-6 model so analytics can decode it later.
- Mask SDD-7 Operator Name through your standard PHI handling rules even though it is plain ST.
- For receivers still on v2.5.1, transform SDD into NTE or local Z-segments; the segment did not exist before v2.7.
How Vorro parses and produces SDD
Vorro treats SDD as the cycle event itself. On inbound: Vorro joins SDD-2 Device Number to the most recent SCP-4 in the same message group, normalizes SDD-4 Device Data State and SDD-5 Load Status against a curated vocabulary, and emits a cycle-event row into the sterilization warehouse keyed on SDD-1 Lot Number. Vendor-specific SDD-6 Control Codes are resolved using the device model recorded on the matching SCP. On outbound: Vorro generates SDD from the cycle event store, populating SDD-1 with the primary lot id, SDD-2 with the registry's device identifier, SDD-4 from the cycle's lifecycle state, and SDD-7 from the authenticated operator on the event. Vorro rejects outbound messages where SDD-1 is empty or where SDD-2 does not resolve to a known device.
