FHIR Chat · UDI cross paradigm IG · devices

Stream: devices

Topic: UDI cross paradigm IG


view this post on Zulip François Macary (Apr 03 2020 at 09:11):

Hi,
In one of the latest drafts of the UDI cross-paradigm IG, I read this statement:
<<A recommended best practice is to use the UDI for validation purposes but to parse and store each of the UDI data components – DI and the applicable production identifiers represented on the device – (e.g., Lot Number, Serial Number, Expiration Date, Manufacturing Date, and/or Distinct Identification Code) – in separate fields.>>
Can someone be more explicit on the expresion “use the UDI for validation purposes” ? What exact kind of validation purposes are addressed?
I registered to the ballot pool for this IG, so I'll probably post the same comment to the ballot. But it would be good to have an immediate answer. Thanks

view this post on Zulip Jose Costa Teixeira (Apr 03 2020 at 09:20):

I guess it would mean that you keep the UDI string as a whole so that if you want to see what was scanned, you can still go back

view this post on Zulip Jose Costa Teixeira (Apr 03 2020 at 09:20):

but it's a guess

view this post on Zulip François Macary (Apr 03 2020 at 10:03):

Thank you Jose. That was also my intepretation. Could we say, then, that the purpose is more of the kind of a safety net, or a debugging purpose, for instance when you configure a new barcode scanner or a new UDI parser and you want to validate the correctness of the process from end to end? I'll see if the statement evolved in the balloted IG. From my point of view, it should a little bit more that the key data is the UDI components.

view this post on Zulip François Macary (Apr 03 2020 at 10:05):

Sorry (a word skipped). I meant "it should emphazise a little bit more that the key data is the UDI components.

view this post on Zulip Jose Costa Teixeira (Apr 03 2020 at 11:39):

in some cases we cannot parse the udi into the components, so you have the full udi and pass it forward to the next entity, and maybe that entity can parse it

view this post on Zulip François Macary (Apr 03 2020 at 11:59):

That's part of the safety net purpose, to me.

view this post on Zulip John Moehrke (Apr 03 2020 at 12:37):

I think the scanned value directly off the device should be considered the primary. Parsing that into the parts is 'art' and that art should be the responsibility of software that is designed to use the UDI, not software designed simply to record the UDI. I have stressed this for many years.

view this post on Zulip François Macary (Apr 03 2020 at 15:00):

Well, the cross-paradigm IG tries to transform 'art' into 'standard' ... defining the data elements for the UDI components in each of the HL7 strandard family.
I see your point, @John Moehrke , although I can't think at the moment, of a kind of software that would be designed to record the UDI and not using it, to some degree.

view this post on Zulip Jose Costa Teixeira (Apr 03 2020 at 17:15):

well, the algorithms to encode the UDI information are standard themselves. so the UDI is a standard that relies on those standards.
The decoding implementation is art.

view this post on Zulip Jose Costa Teixeira (Apr 03 2020 at 17:18):

As for identifiers, the one that comes out of the UDI is the primary for some purposes (although which value from the UDI? the AIDC form or the HRF?)
AIDC = the actual string of characters in the barcode, with characters like 1d)
HRF =the human readable form which has fancy stuff like numbers in parenthesis dto distinguish the fields)

view this post on Zulip Jose Costa Teixeira (Apr 03 2020 at 17:18):

then the values are parsed, and the parsed values are the ones that are useful in operations. To see if it is the right product, or to see if it is expired, etc.

view this post on Zulip Jose Costa Teixeira (Apr 03 2020 at 17:19):

So in any case we need both.


Last updated: Apr 12 2022 at 19:14 UTC