Unique Device Identifiers in FHIR

Oct 31, 2013

The FDA and partners around the world are in the process of introducing a new identification framework for medical devices called the “Unique Device Identifier” (UDI). They asked for FHIR to “support” UDI. But what does that mean? First, some background on what a UDI is, and then some analysis of the use cases for UDI in the scope of FHIR.

What a UDI is

A UDI is a barcode (or series of barcodes, or even an RFID) on a medical device that carries the following information:

  • Device Identifier (Mandatory)
  • Lot Number
  • Serial Number
  • Manufacture date
  • Expiry Date

The first element is the key piece of data - it represents the key that can be used to look up information about the device in the public device registry (GUDID or equivalent). It is referred to as the DI (Device Identifier). There’s also the other fields, which are called the PI (Production Information).

The UDI may identify a specific instance of a device (e.g. no other device will have the same UDI), or it might not - it’s up to the manufacturer to decide whether to put a serial number in the PI. This example from the FDA web site shows a prototypical (and fictional) device label:

[caption id=”” align=”alignnone” width=”498”] UDI example[/caption]

The UDI is represented a the bottom right, in two forms, the barcode and the human readable information below it. Here’s a different example, just the barcode (a GS1 example):

 

This UDI is understood as:

(01) GTIN DI (A DI defined byGS1) 00614141999996
(17) Expiry date 1-Jan 2010 (YYMMDD)
(10) Batch number 123ABC
(21) Serial number 1234567890

There’s some subtleties around this barcode, I’ll discuss this more below.

Use cases for the UDI

The UDI comes out of the supply chain, and it seems that the use of the UDI is well understood there. But it’s less well understood what the goals of support UDI in the space that FHIR occupies (patient management / clinical workflow / clinical record, mainly). It’s been hard to get a good set of requirements. This is what I’ve got so far:

  • The primary use cases are to allow the device to be looked up in the registry, and to foster analysis of the impact of product recalls
  • It would be nice to use the UDI to track an instance of a device, but it’s not reliable for this generally, because it doesn’t need to have a serial number
  • In particular, tracking the UDI for patient implants, so that a clinician can see information about the patient’s implants, manage recall issues, and track adverse events

But still, much is unknown. For instance:

  • When do systems need to consult the registry?
  • Which systems need to understand the internal structure of the UDI? (Is it all of them?)
  • If you have the UDI which contains production information, do you need to exchange the production information separately? Or do you assume that the other systems can extract the PI from the UDI? what if there is production information available that’s not in the UDI? What if they source differs?

So many questions. But at least I got an answer on one question. I wanted to know whether there was a need to exchange the raw UDI, or whether you could just break it up into it’s parts and send the parts in separate slots in the message. I identified 3 reasons why you’d need to send the raw UDI:

  1. Because you need to reproduce the original UDI for display to a human user (so they can verify the device information matches themselves). Since the order of the parts is optional, you need to original to show it correctly to the user
  2. Because some systems don’t know how to process the UDI at all, but gather it from the device (is that realistic? allowed?)
  3. Because the slots for exchanging the PI don’t exist anyway, and all you can do is the full UDI as a single identifier

The answer to that is that FDA strongly endorses the first use case, and believes that this is necessary.

GS1 Barcode Issues

So it turns it there’s a trick to that with GS1 barcodes (This section is specifically about GS1 barcodes - I haven’t investigated the others). Consider this example from above:

 

This is actually a dual representation. Most obviously, there’s the human readable information, which is (01)0061414999996(17)199191(10)123ABC(21)1234567890. But when a bar code scanner scans the bar code, what it might get depends on it’s configuration. The full representation of the barcode is ]C101006141419999961710010110123ABC211234567890. ]C1 is the ISO/IEC symbology identifier indicating GS1 formatted data in a code 128 (I'm not clear whether code 128 is the only way UDIs are represented btw). is a non-visible ASCII character (29) which is a separation marker that marks the end of the variable length batch number. Without that separation marker, that number is not parseable. For example, when I scanned this barcode with a standard USB bar code scanner that drops the scanned barcode into the keyboard buffer, what I got in my application was "01006141419999961710010110123ABC211234567890" - which is not parsable. What exactly the barcode scanner returns depends on how it is configured, and also it appears that the separator character doesn't make it through the keyboard buffer. The take away message is that scanning and parsing the UDI may require special bar code scanning support which is different to existing arrangements in clinical practice.

Exchanging the UDI

So the question is, which representation should be used to exchange the UDI in practice? Well, if the goal is to be able to show to the user - and it is - you need to exchange the Human Readable Information (HRI) - that is, the form (01)0061414999996(17)199191(10)123ABC(21)1234567890. Conveniently, this is easily parseable. I’m yet to check the bar codes from the other definers of UDI.

There’s another HL7 concern here - HL7 is careful to distinguish between type and instance identifiers. Because this makes a big difference to how you use these numbers, and rely on them. So HL7 typically calls the first (type identifier) a “code” and the second (“instance identifier”) is typically called “id”. UDI is one or the other, depending on it’s specific contents in the PI… that’s tricky.

So, at least in the context of FHIR, supporting UDI becomes clear. Anywhere a device is involved in the care process, the resource that describes the process should reference a device resource - which describes the resource. The device the resource has the following simple structure:

This has a specific field for the whole UDI, and other fields for the parts of the UDI  - the DI goes in the type as a code, and the PI goes in the appropriately named fields. These can be filled out from the UDI or from other sources. Concerning the UDI, the spec says (or will, when it is next updated):

  • The UDI has it’s own element, which  carries the human readable representation of the UDI shown in the bar
  • The UDI may identify an instance of a device uniquely, or it may just identify the type of the device.
  • A portion of the UDI - the DI part - can be extracted from the UDI and/or carried in the type element. When required, it can be used  to look up information about the device through the GUDID.
  • Where the device has an assigned UDI, the other details carried in the resource (lot, expiry date etc) SHALL be consistent with the information encoded in the UDI or reigstered in the GUDID.

I’ve written this into the draft, which will make it’s way to the website soon, and then it will under go the normal ballot review process (all this is driven by a FDA ballot comment on FHIR that UDI needs to be supported)