Skip to end of metadata
Go to start of metadata

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:

'kind' attributes:

  • deviceIdentifier
  • type
  • name
  • jurisdiction
  • issuer
  • manufacturer
  • model
  • version
  • safety

'instance' attributes:

  • identifier (serial number)
  • carrierAIDC
  • carrierHRF
  • entryType
  • lotNumber
  • manufactureDate
  • expirationDate
  • status


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:

  1. Create a “deviceKind” which represents a DI under a device. In this way, a Device can have 0 to several “authorized” Dis.
  2. Simply consider “device” resource as “deviceKind” (as per Challenge 1 option 1 a); allow a Device (=deviceKind) to contain several devices (=deviceKinds).
  3. 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.


  • No labels

1 Comment

  1. Last year we had a discussion on what is considered a Medical Device.
    A few questions came to mind.

    One of these questions was:
    Can software be considered a Medical Device?

    I started to look for an answer.

    I found one publication from The International Medical Device Regulators Forum provides Key Definitions in a 
    document published in December 2013.

    I sent an email to the FDA Device Determination department.

    From: Howard Edidin [mailto:]
    Sent: Tuesday, March 20, 2018 5:42 PM
    To: Device Determination
    Subject: Medical Device Clarification

    Does a medical device need to be a physical machine?

    The reason I am asking is that we are developing an Artificial intelligence Bot Service. The service uses Cognitive Services to record a patient's mental state when answering questions.
    The Bot Service will be provisioned and managed by an IoT hub in a Healthcare facility. Could the
    Bot Service be classified as a medical device?

    I received the following response:

    From: Device Determination Sent: Monday, March 26, 2018 10:21 AM
    To: Howard Edidin; Device Determination>
    Subject: RE: Medical Device Clarification

    Hello Howard:

    A device used to record a patient’s mental state could be considered a medical device if it is
    intended to tre mitigate and/or diagnose a patient. This response represents my best judgment on
    how the product would be regulated. This response is not a classification decision and does not
    constitute FDA clearance or approval for commercial distribution of your product.

    Thank you,

    FDA Device Determination

    The FDA published a document, Software as a Medical Device (SAMD): Clinical Evaluation in December 2017.

    Is this a new DeviceKind?