The DEV (Device) segment carries detailed information about a medical or non-medical device used in healthcare. It records the device's unique identifiers, manufacturer, brand, model, manufacturing and expiration dates, serial and lot numbers, and other operational details. DEV is used to provide supplementary device information that enhances participation data captured in the PRT (Participation Information) segment.
DEV is a detail segment introduced in HL7 v2.9 to support modern device tracking, supply chain visibility, and compliance requirements in healthcare messaging. Medical devices include durable (reusable) medical equipment, implantable devices, and disposable diagnostic and treatment equipment. Non-medical devices may include machines, computers, applications, and other items used in healthcare contexts.
Purpose
The purpose of DEV is to express comprehensive information about a device that participates in a healthcare event. When a PRT segment in a message references a device, DEV provides the full specification: manufacturer, brand name, model, lot number, serial number, manufacture and expiry dates, safety characteristics, and implantation status. This enables downstream systems to track device history, validate equipment compliance, manage device recalls, support supply chain and inventory management, and populate device registries.
Because DEV is a detail segment, it supplements data already referenced in a PRT segment. DEV-2 (Unique Device Identifier) or DEV-3 (Device Type) must match the corresponding PRT-10 (Participation Device) or PRT-22 (Participation Device Type), creating a logical link between the device participation and the device specification.
Used in
DEV is a device-detail segment used in messages that reference devices through PRT segments, such as the ORU^R01 (Unsolicited Observation Message) and OML^O33 (Laboratory Order Message). Within those messages, DEV repeats once per unique device that requires detailed specification. The device identifier in DEV-2 or device type in DEV-3 must align with the device referenced in the PRT segment to maintain referential integrity.
Field-by-field reference
Source: NIST HL7 v2.9 segment definition (https://usnistgov.github.io/v2plusDemo/segment-definition/DEV.html) for sequence, name, data type, cardinality, and vocabulary. Length and exact table numbers are published where specified; otherwise — is used.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| DEV-1 | Action Code | id | 2 | R | — | 0206 | Code defining the action to be taken for this segment (add, update, delete) |
| DEV-2 | Unique Device Identifier | ei | — | C | — | — | Unique identifier for the device; must be valued if DEV-3 is empty |
| DEV-3 | Device Type | cne | — | C | Y | 0961 | Device type code; repeats for multiple type classifications; must be valued if DEV-2 is empty |
| DEV-4 | Device Status | cne | — | O | Y | 0962 | Current operational status of the device |
| DEV-5 | Manufacturer/Distributor | xon | — | O | — | — | Name and identifier of the manufacturer or distributor |
| DEV-6 | Brand Name | st | 60 | O | — | — | Brand or marketing name of the device |
| DEV-7 | Model Identifier | st | 60 | O | — | — | Manufacturer's model identifier |
| DEV-8 | Catalogue Identifier | st | 60 | O | — | — | Catalogue or part number assigned by the manufacturer |
| DEV-9 | UDI Device Identifier | ei | — | O | — | — | Unique Device Identifier (UDI) as assigned by regulatory authorities (e.g., FDA) |
| DEV-10 | Device Lot Number | st | — | O | — | — | Manufacturer's lot or batch number |
| DEV-11 | Device Serial Number | st | — | O | — | — | Manufacturer's serial number for this device instance |
| DEV-12 | Device Manufacture Date | dtm | — | O | — | — | Date and time the device was manufactured |
| DEV-13 | Device Expiry Date | dtm | — | O | — | — | Date and time after which the device should not be used |
| DEV-14 | Safety Characteristics | cwe | — | O | Y | 0963 | Safety or hazard classification of the device; repeats for multiple characteristics |
| DEV-15 | Device Donation Identification | ei | — | O | — | — | Identifier assigned to track organ or tissue donation |
| DEV-16 | Software Version Number | st | — | O | — | — | Version identifier for embedded or controlling software |
| DEV-17 | Implantation Status | cne | — | O | — | 0795 | Whether the device was implanted and its current implantation status |
Most-used fields
DEV-1 (Action Code) is mandatory and indicates whether the segment is being sent to add, update, or delete a device record. DEV-2 (Unique Device Identifier) is highly used when the device can be uniquely identified (e.g., by UDI or regulatory identifier). DEV-3 (Device Type) is conditional and used when the device is referenced by type classification rather than a unique identifier. DEV-9 (UDI Device Identifier) is increasingly critical due to regulatory requirements for device traceability in healthcare systems. DEV-12 and DEV-13 (Manufacture and Expiry Dates) are frequently populated to track device lifecycle and compliance. DEV-10 and DEV-11 (Lot and Serial Numbers) are essential for recalls, inventory management, and forensic traceability. DEV-5, DEV-6, DEV-7, and DEV-8 (Manufacturer and model information) are commonly included to contextualize the device specification.
Version differences (v2.9 introduction)
The DEV segment was introduced in HL7 v2.9 as part of the healthcare industry's shift toward device identification, traceability, and supply chain management. Prior HL7 versions (v2.5.1 through v2.8.2) did not include a dedicated device segment; device information was either absent or embedded in text fields. The DEV segment structure in v2.9 is stable as of the 2021-Jan release and remains the current definition.
Common mistakes
A frequent error is omitting both DEV-2 and DEV-3, leaving the device unidentified; one or both must be valued. Another mistake is populating DEV-2 with a device type when DEV-3 (Device Type) should be used instead, causing downstream parsing ambiguity. Teams also fail to populate DEV-12 and DEV-13 when those dates are critical for compliance or recall management. Implementers sometimes place free-text device descriptions in DEV-2 instead of using the structured identifier components, which breaks normalized lookups and regulatory compliance. Finally, a common oversight is not validating that DEV-2 or DEV-3 matches the device referenced in the PRT segment's PRT-10 or PRT-22, creating orphaned device records.
Examples
Minimal DEV (device type only):
DEV|A|^IV Pump^0961
Fully-populated DEV with unique device identifier and UDI:
DEV|A|00643169001510|^Cardiac Monitor^0961|A|^Philips Healthcare|HeartStart|MRx|CM-MRx-2019|5986010001234567890|LT-2019-04567|SN-8834-221650|20190315120000|20260314|Defibrillator^0963|00643169001510^FDA UDI|^2.0
Annotated breakdown:
DEV|A|00643169001510|^Cardiac Monitor^0961|A|^Philips Healthcare|HeartStart|MRx|CM-MRx-2019|LT-2019-04567|SN-8834-221650|20190315120000|20260314|Defibrillator^0963|00643169001510^FDA UDI|^2.0
| | | | | | | | | | | |
| | | | | | | | | | | +--> DEV-17 Implantation Status (CNE)
| | | | | | | | | | +-------------------> DEV-16 Software Version Number (ST)
| | | | | | | | | +-----------------------------> DEV-15 Device Donation Identification (EI)
| | | | | | | | +--------------------------------> DEV-14 Safety Characteristics (CWE)
| | | | | | | +------------------------------------> DEV-13 Device Expiry Date (DTM) 2026-03-14
| | | | | | +----------------------------------> DEV-12 Device Manufacture Date (DTM) 2019-03-15
| | | | | | +---> DEV-11 Device Serial Number (ST)
| | | | | | +----> DEV-10 Device Lot Number (ST)
| | | | | +----> DEV-9 UDI Device Identifier (EI)
| | | | | +-> DEV-8 Catalogue Identifier (ST)
| | | | | +--> DEV-7 Model Identifier (ST)
| | | | | +--> DEV-6 Brand Name (ST)
| | | | +-------------------> DEV-5 Manufacturer/Distributor (XON)
| | | +----------------------> DEV-4 Device Status (CNE) = A (Active)
| | +------------------------------------------> DEV-3 Device Type (CNE)
| +------------------------------------------------------------> DEV-2 Unique Device Identifier (EI)
+------------------------------------------------------------> DEV-1 Action Code (ID) = A (Add)
In-context excerpt 1 — DEV in an ORU^R01 observation message, following a PRT segment that references the same device:
MSH|^~&|LAB|HOSPITAL|CENTRAL|EHR|20260701140000||ORU^R01^ORU_R01|MSG00101|P|2.9
PID|||123456^^^MRN||DOE^JOHN||19700101|M
OBR|1|OBR123|OBX456|85025^Blood Bank Panel||||20260701||||||20260701
OBX|1|CE|85025^Blood Bank Panel||ABO^O^LN|||||F
PRT|^^^Specimen Processing Equipment||20260701140000||60551^Blood analyzer^LN|20260701140000
DEV|A|00643169001234|^Blood Analyzer^0961|A|^Siemens Healthcare|Atellica^|^Analyzer-5|SN-LAB-98765|LT-2026-001234|20260101|20270101
In-context excerpt 2 — DEV in an OML^O33 laboratory order message with medication pump device:
MSH|^~&|PHARMACY|HOSPITAL|ORDER|ENTRY|20260701093000||OML^O33^OML_O33|MSG00102|P|2.9
PID|||789654^^^MRN||SMITH^JANE||19850615|F
ORC|NW|PHARM-2826|PHARM-2826-EXEC|IP|CM|N|^^^^R|20260701093000
OBR|1|PHARM-2826|LAB-001|87805^Vancomycin Level^LN||||20260701093000
PRT|^^^Medication Pump Delivery|||99291^Programmable Pump^LN
DEV|A|IV-PUMP-2019-X567|^IV Infusion Pump^0961|A|^Baxter Healthcare|MultiRate|^IVP-500|LOTBAX-2026-0045|SN-PUMP-006654|20190501|20290501|Medication Infusion Device^0963
FHIR mapping
There is no segment-level ConceptMap published in the v2-to-FHIR Implementation Guide for DEV, so the target is "Not mapped at the segment level." Conceptually, DEV maps to the Device resource: DEV-2 (Unique Device Identifier) and DEV-9 (UDI Device Identifier) align with Device.identifier, DEV-6/DEV-7/DEV-8 (Brand/Model/Catalogue) correspond to Device.deviceName, DEV-5 (Manufacturer) aligns with Device.manufacturer, DEV-12 and DEV-13 (Manufacture and Expiry Dates) map to Device.manufactureDate and Device.expirationDate respectively, and DEV-17 (Implantation Status) informs Device.status. Because no normalized mapping is standardized, any DEV-to-Device transform must be defined locally and verified per interface.
Engine considerations
DEV is a repeating detail segment, so an interface engine must match each DEV occurrence to the correct device referenced in the preceding PRT segment via DEV-2/DEV-3 alignment with PRT-10/PRT-22. Engines should validate that at least one of DEV-2 or DEV-3 is populated, since both cannot be empty. The EI data type in DEV-2 and DEV-9 requires careful component parsing to extract identifier, namespace, and universal ID components; UDI identifiers in particular may use specific formatting standards (e.g., FDA UDI-DI and UDI-PI). Date-based fields DEV-12 and DEV-13 use the DTM type, which supports full timestamp granularity; engines should normalize dates consistently. The CWE/CNE types in DEV-3, DEV-4, and DEV-14 require vocabulary lookup and validation against the published HL7 tables (0961, 0962, 0963 respectively) to ensure compliance.
How Vorro parses and produces DEV
When Vorro parses DEV, each occurrence is decomposed into a normalized device record linked to the participating device established from the preceding PRT segment. DEV-2 (Unique Device Identifier) and DEV-9 (UDI Device Identifier) are parsed into their EI components so that identifier, namespace, and source are stored separately. DEV-3 (Device Type) is expanded into individual CWE components for text, code, and coding system. Manufacturer information from DEV-5 is decomposed into organization name and organizational identifier. Date fields DEV-12 and DEV-13 are parsed into discrete timestamp values for range queries and compliance reporting.
When Vorro produces DEV, it emits one segment per device on the source record, assigns DEV-1 (Action Code) based on the operation (A for add, U for update, D for delete), and validates that at least DEV-2 or DEV-3 is populated. Device identifiers and UDI values are reassembled into EI format with proper component delimiters. Manufacturer names and identifiers are reassembled into the XON structure, and all dates are formatted as complete DTM timestamps.
Related pages
- PRT Segment: Participation Information
- ORU^R01 Message: Unsolicited Observation Message
- OML^O33 Message: Laboratory Order Message
- EI Data Type: Entity Identifier
- CNE Data Type: Coded with No Exceptions
- XON Data Type: Extended Organization Name
