Device — detail: UDI and lifecycle
Lifecycle of an individual medical device, from unboxing to disposal. UDI (Unique Device Identifier) is the spine of vigilance traceability.
UDI: DI + PI
The UDI (Unique Device Identifier) has two parts:
- DI (Device Identifier) — static part identifying the model. Issued by GS1, HIBCC, ICCBBA or another AIDC.
- PI (Production Identifier) — dynamic part: lot, serial, manufacture date, expiration date.
In R5, the UDI lives in udiCarrier with deviceIdentifier (DI),
issuer (issuing system), jurisdiction (regulator FDA, EUDAMED,
ANSM), and carrierHRF (Human Readable Form).
Lifecycle
The status field tracks the phase:
| Code | Phase |
|---|---|
active | In service. |
inactive | Stored, unassigned. |
entered-in-error | Entered in error. |
For the operational cycle (calibration, maintenance), use availabilityStatus
(lost, damaged, destroyed, available).
Device <-> DeviceDefinition link
Device carries a physical instance. DeviceDefinition carries the model. A Device
instance points to its DeviceDefinition via definition. This is exactly the
Medication / MedicationKnowledge or Specimen / SpecimenDefinition pattern.
JSON example
{
"resourceType": "Device",
"id": "infusion-pump-001",
"udiCarrier": [{
"deviceIdentifier": "00643169007222",
"issuer": "http://hl7.org/fhir/NamingSystem/gs1",
"jurisdiction": "http://hl7.org/fhir/NamingSystem/fda-udi",
"carrierHRF": "(01)00643169007222(17)280128(10)BATCH123(21)SN456789"
}],
"status": "active",
"manufacturer": "Medtronic",
"manufactureDate": "2025-07-15",
"expirationDate": "2028-01-28",
"lotNumber": "BATCH123",
"serialNumber": "SN456789",
"type": [{
"coding": [{
"system": "http://snomed.info/sct",
"code": "126097006",
"display": "Infusion pump, electronic"
}]
}],
"definition": {
"reference": "DeviceDefinition/medtronic-pump-model-x"
},
"owner": { "reference": "Organization/hospital-saint-louis" }
} Common pitfalls
- UDI missing — UDI is mandatory for FDA vigilance since 2014. EUDAMED EU MDR since 2022.
- DI/PI confusion — the DI never changes for a model. Reusing the DI on a new lot is forbidden.
- Issuer poorly qualified — declaring
issuerlets receivers parse correctly (GS1 vs HIBCC vs ICCBBA algo). - No DeviceDefinition reference — a Device without
definitionmakes manufacturer alerts hard to correlate.