2013-11-07 TSC UDI Task Force

From HL7 TSC
Jump to navigation Jump to search

TSC UDI TF

Meeting Info/Attendees

HL7 TSC Meeting Minutes

Location: https://attendee.gotowebinar.com/register/1718485351410160385

Date: 2013-11-07
Time: 4:00 PM U.S. Eastern DAYLIGHT
Facilitator: Paul Knapp Note taker(s): Lynn Laakso
Quorum not defined
Attendee role
x Woody Beeler MnM cochairs, FTSD cochair
x Lorraine Constable
x Todd Cooper DEV cochair
x Pat Distler, HIBC
x Matt Graham Mayo, Mobile Health cochair
x Grahame Grieve FHIR FMG, MnM
x Robert Hankin
x Christian Hay GS1
x Paul Knapp FTSD co-chair, UDI Task Force Chair, ITS and FM cochairs, FMG
x Behnaz Minaei works with Terrie on UDI project
x Terrie Reed FDA informatics and ONC with UDI incorporation into certification activieis
x John Rhoads cochair DEV
x Paul Schluter with DEV and liaise with Continua and IHE PCP
x Pat Van Dyke EHR cochair, ADentalA liaison -->
x Pele Yu Child Health

Agenda

Reviewed online

Notes:

UDI rule out for guidance/comment until about Nov 24 2013


Questions (illustration)

Minutes

Minutes/Conclusions Reached:

  1. Roll Call
  2. Review draft agenda; Terrie asks for an idea of timeframes for tasks to follow e.g. harmonization. Woody reports that if we need changes to RIM or terminologies that is conducted in a harmonization process that will occur in two weeks. So far it doesn't appear to need harmonization.
  3. Task Force
    Definition: a purpose tasked committee with a lifetime to match the issue
    Objectives: to define a conceptual model for UDI to ensure interoperable implementation across the suite of HL7 standards (v2, v3 message4, v3 CDA, FHIR
    Goals for today:
    • Review FDA-UDI storage proposal and coding
    • Review overlap and approaches to ISBT
    • Review overlap and approaches to HIBC
    • Next steps
  4. Review FDA-UDI
    1. Always transmit the entire Human Readable string.
    2. Create/Know the OID/URI etc for the FDA-URI. By Issues or singular.
    3. Same for the parts - decomposition is optional?
    4. Are there OIDs/URI?
    5. When only a part is required?
    6. Are parts ordered?
    7. Date context issues. – not Task force, but community issue.
    8. Bar code parsing issues. – not Task force, but community issue.
      corrections identified to grid: table replicated three times and have different AIs in each. DI is not exclusively GS1. Woody clarifies that the AI distinguishes its type. See www.fda.gov/udi. Navigate to GUDID guidance, Appendix C, page 51. Noted that dates don't contain centuries. Christian confirms that the order is not fixed but the first entry (issuing agency) is 01. Only the last two of the table are optional.
      Christian cautions that for bar code reader width the bar codes are often broken into parts. Paul asks if they must be stored at two things or concatenated? If a change is needed Terrie suggests we provide feedback to the public comment period
      Woody asks if the parentheses are not part of the bar code, and the lot number and serial number are variable length, what if there is a 21… there is a control character read by the bar code that Paul has tested with. However Grahame's bar code reader typical to AUS misses the separator characters.
      initial character is parentheses in human readable or 0 in machine representation
  5. Review ISBT 128 or ICBBA
    1. Always transmit the entire Human Readable string.
    2. Create/Know the OID/URI etc for the FDA-URI. By Issues or singular.
    3. Same for the parts - decomposition is optional?
    4. Are there OIDs/URI?
    5. When only a part is required?
    6. Are parts ordered?
    Literal information is more exchangeable without escape characters, etc. The serial and donation IDs are required. Device IDs will follow UDI and then production identifiers are separate.
    Three character date is julian
    • Initial character is =
  6. Review HIBCC
    1. Always transmit the entire Human Readable string.
    2. Create/Know the OID/URI etc for the FDA-URI. By Issues or singular.
    3. Same for the parts - decomposition is optional?
    4. Are there OIDs/URI?
    5. When only a part is required?
    6. Are parts ordered?
  • DI is first but others are optional, variable length 58-75 (75 for human readable).
  • Woody notes that it is parseable with human readable separator character, although this can come as separate pieces confirms Christian. Again, there is not a century indicator. Christian distinguishes the information you process from the information you read on the bar code. Bar coded devices do not last 60 years so the century in the bar code is irrelevant. Paul interprets this to say that the century should be interpreted when storing the information.
  • What is the form to exchange then between systems? The human readable form of GS1 was exchangeable as well as parseable, for example.
  • Initial character is + or &
  • do we use the same OID for representing the FDA UDI which includes all three formats or one for each format. E.g. ball and socket joints as devices, come from four manufacturers each issuing their own UDI. Should each of these be its own OID? Woody asserts that there can only be one OID according to Grahame.
  • concepts represented in each type of UDI, may need an OID for each such concept, e.g. lot number in GS1 versus HIBCC lot number, etc.
  • Donation ID and Expiration are same data structures on devices and blood. There is also a time associated with the date notes Pat D for blood products. Paul Schluter notes that date of capture is mandatory part of message.
  • Of the three different styles of UDI, in full wire form, should there be three OIDs for the styles or one for "FDA UDI". Grahame asserts if you have the DI with the prefix that tells you the type, there is not a need for additional OID. Woody adds that as a namespace with unique values across the namespace it is consistent. Grahame notes existing OIDs were defined incorrectly as specified in FDA documentation for SPL. OIDs have been created 15 years according to Christian, and Grahame notes the GS1 OID is correct. The other OIDs for ISTBCC OID in the SPL message is something else. Correcting this would be in the Common Product Model agrees Terrie for the SPL IG.
  • What about assigning OIDs to the decomposable elements of the code? Manufacturers should have their own OID for their lot numbers. There's no way to attach the lot number OID in the bar code. Or do you define a lot number up to 20 characters to cover all three UDI types? Can you send a piece of the decomposition of the UDI separate from the UDI? Value of exchange of decomposed components of UDI not obvious. Grahame can see a use case for sending the DI without the PI but it doesn't represent a UDI.
  • Paul asks about modeling in V2 - no immediate response from V2 community members.
  • Terrie notes that GS1 has their own OIDs, Pat D notes they have one for ICCBA but does not know the purpose for which it was registered. Woody points out that an organization can issue sub-OIDs and should have someone managing the tree of OIDs issue. Grahame notes we need to find out the HIBCC OID. Paul points out there are a dozen different date formats used in the HIBCC spec and they would need to have some sort of OID association.
  1. Next steps.
    • Paul will pull together elements of discussion and try to develop a picture for modeling and review on next week's call.
    • Harmonization is Nov 20th if we need any changes but Woody doesn't hear any candidates. The deadline is technically on Sunday to submit items for Harmonization but we might consider submitting a placeholder. FDA comment period ends Nov 24th as well , and Woody notes that the guidance on FDA's site does not specify the +/- 50 year century rule and the algorithm should be in the guidance document. If HIBCC's date disambiguation algorithm is different from GS1 it's even more complicated.
  2. Adjourn

Switching GTM for webinar was problematic; review for next week.

Adjourn 5:31 PM.



Next Steps

Actions (Include Owner, Action Item, and due date)
  • .
Next Meeting/Preliminary Agenda Items


© 2013 Health Level Seven® International. All rights reserved.