Patient safety requires consistent identification of products (including product type and also serial number, UDI) across all "healthcare products" used at the point of care - especially for regulated products. This is essential when handling recalling or any other regulatory follow-up. This unequivocal identification of products is one key requirement addressed by UDI.
In addition to identifying Kind and Instance of a device, other challenges are found for UDI harmonization. These challenges are interdependent and any solution must address all of them.
Challenge 1: Specification of a Kind vs Identification of a physical Instance
Currently, the Device resource represents both an ‘instance’ of a device (e.g., this IM pin which has serial number 123) and a ‘kind’ of device (e.g., 3ml syringes from a certain vendor). The list of the Device attributes/elements associated with kind and instance respectively are:
- identifier (serial number)
To clearly differentiate the kind of device from the instance of a device, several proposals have been put forth:
Option 1: Create separate resources for kind vs instance of Device
This approach would mean that there is a “device kind” resource and a “device instance” resource. The payload of the “device instance” resource could be either
a) containing only “instance” elements or attributes (in which case, when specifying an instance, implementers typically have to create an “instance” resource and provide/contain/refer to a “kind” resource as well). This option can be reusable / harmonized with other resources e.g. BiologicallyDerivedProduct,..
b) Containing “kind” and “instance” attributes (in which case, when specifying an instance, the resource would contain the kind information as well – possibly duplicate from any existing “kind” resource.
Option 2: Create a Device profile to represent a Device Kind
This approach would mean that the same resource could be used for “kind” and “instance”, and a profile would determine which attributes are to be used in each circumstance. This could be similar to option 1b) above.
Option 3: Reorder the elements and group by kind and instance within the Device resource.
This approach is the simplest. It is a smaller change than the previous approach – elements can be reordered in any case, and they can be grouped so that the difference between “kind” and “instance” is not scattered in the resource.
Challenge 2: Representation of multipart devices and UDI for multipart devices
Currently, the Device resource only permits a single UDI, which does not allow for devices that are composed of multiple parts each with a separate UDI. The following options are proposed to allow representation of UDI for multipart devices.
Option 1: Group individual Devices using the Procedure resource focalDevice element.
There would be as many devices as necessary represented, but each device will have zero to one DI and UDI. There is no way to define the relationship between devices with DeviceComponent unless add a reference of DeviceComponent in Procedure.
Option 2: Change Device to support a device that has zero to one DIs (represent type) with multiple UDIs (instance).
This can be done in different ways:
- Create a “deviceKind” which represents a DI under a device. In this way, a Device can have 0 to several “authorized” Dis.
- Simply consider “device” resource as “deviceKind” (as per Challenge 1 option 1 a); allow a Device (=deviceKind) to contain several devices (=deviceKinds).
- In addition to option 2 above, add an element to Device to be able reference other Devices resources. This would allow representation of a number of inter-related devices within a device system. This option is similar to the Device harmonization discussion below.
Challenge 3: Harmonization between Personal Healthcare Devices (PHD) with Point of Care Device (POCD)
Similar to the 3rd option above for UDI for multipart devices, there is active discussion within the Devices working group to harmonize the representation of simpler Personal Healthcare Devices (PHD) with Point of Care Device (POCD) by merging DeviceComponent within Device and allow multiple component Devices reference the 'parent' device.
Challenge 4: Guidance on “Device identifier” as “identifyer of (Gforge 15516)
GForge issue 15516 requires clarification of how to identify an instance. This is handled by Challenge 1 above, and should be addressed consistently across different products.